From bstrick@plano.net Sat Jul 01 16:39:16 1995 
Received: from dns (dns.plano.net [204.215.60.2]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with SMTP id QAA31588 for <hfsig@tapr.org>; Sat, 1 Jul 1995 
16:39:12 -0500 
Received: from nt-35 (aux44.plano.net) by dns (5.x/SMI-SVR4) 
id AA12115; Sat, 1 Jul 1995 16:41:12 -0500 
Date: Sat, 1 Jul 1995 16:41:12 -0500 
Message-Id: <9507012141.AA12115@dns> 
X-Sender: bstrick@plano.net 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 
From: bstrick@plano.net (Bob Stricklin) 
Subject: Your DSP-93 
X-Mailer: <Windows Eudora Version 2.0.2> 


I did mail your DSP-93 on Friday morning. It was insured so if it does not 
show up in a while let me know. 


Also I put in a set of new docs including an operation manual. Also left in 
the older assembly manual in case it has something that will help you out. 
Can not recal if the schematics were included. If not let me know and I will 
mail you a set. 


Bob Stricklin, N5BRG 


From bstrick@plano.net Sun Jul 02 08:26:17 1995 
Received: from dns (dns.plano.net [204.215.60.2]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with SMTP id IAA04931 for <hfsig@tapr.org>; Sun, 2 Jul 1995 
08:26:11 -0500 
Received: from nt-35 (aux31.plano.net) by dns (5.x/SMI-SVR4) 
id AAQ0123; Sun, 2 Jul 1995 08:28:13 -0500 
Date: Sun, 2 Jul 1995 08:28:13 -0500 
Message-Id: <9507021328 .AAQ0123@dns> 
X-Sender: bstrick@plano.net 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 
From: bstrick@plano.net (Bob Stricklin) 
Subject: Re: [HFSIG:440] Your DSP-93 
X-Mailer: <Windows Eudora Version 2.0.2> 


Sorry, I posted this note to the wrong address. 


>I did mail your DSP-93 on Friday morning. It was insured so if it does not 
>show up in a while let me know. 

> 

>Also I put in a set of new docs including an operation manual. Also left in 
>the older assembly manual in case it has something that will help you out. 
>Can not recal if the schematics were included. If not let me know and I will 
>mail you a set. 


> 
>Bob Stricklin, N5BRG 
> 
> 


Bob Stricklin, N5BRG 


From gjones@tenet.edu Mon Jul 03 03:48:18 1995 

Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) 

by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id DAA14763; Mon, 3 Jul 

1995 03:48:04 -0500 

Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id 

DAA31049; Mon, 3 Jul 1995 03:48:03 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199507030848 . DAA31049@Leslie-Francis.tenet.edu> 

Subject: 1995 ARRL DCC (Papers Deadline) 

To: aprssig@tapr.org (BBS SIG mailing), bbssig@tapr.org (BBS SIG mailing), 
hfsig@tapr.org (HF SIG mailing), netsig@tapr.org (NETSIG mailing), 
amsat-bb@amsat.org (AMSAT BB Mail Group), tapr-tnc@tapr.org 

Date: Mon, 3 Jul 1995 03:48:03 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 3204 


1995 ARRL Digital Communications Conference 
September 8-10th, 1995 
Arlington, Texas (minutes from DFW airport) 


KKKKKKKKKKKKK PAPERS DEADLINE July 21st, 1995 xxxkkkkkKKKKKK 


Anyone interested in digital communications is invited to submit a 
paper for publication in the Conference Proceedings. Presentation at the 
Conference is not required for publication. If you know of someone who is 
doing great things with digital communications, be sure to personally tell 
them about this! Papers are due by July 21, 1995, and should be submitted 
to Maty Weinberg, ARRL, 225 Main Street, Newington, CT 06111 or via the 
Internet to mweinberg@arrl.org. Please contact Maty for detailed format 
requirements. 


Full text is available on the Internet: 
FTP: ftp.tapr.org WWW: hhtp://www.tapr.org/tapr E-Mail: tapr@tapr.org 


The ARRL Digital Communications Conference is an international forum 
for radio amateurs in digital communications, networking, and related 
technologies to meet, publish their work, and present new ideas and 
techniques for discussion. Presenters and attendees will have the 
opportunity to exchange ideas and learn about recent hardware and software 
advances, theories, experimental results, and practical applications. The 


Digital Communications Conference is not just for the digital elite, but for 
digitally-orientated amateurs of all levels of experience. 


The 1995 Digital Communications Conference will be held on September 
8-10th, 1995 in Arlington, Texas. Arlington is just minutes away from the 
Dallas/Ft. Worth International Airport, which is located in the middle of 
the country, and airfares have never been cheaper for this 
conveniently-located conference. 


In addition to the presentation of papers on Saturday, two workshops 
will be held during the conference. On Friday, Keith Sproul, WU2Z, will 
hold a workshop on APRS packet-location software. Keith is the Chair of the 
TAPR APRS Special Interest Group, developer of the Macintosh version of 
APRS, and a leader in the area of APRS technology. This is a unique 
opportunity to gain insight into this fast growing new digital aspect of 
amateur operations that combines computers, packet radio, and GPS (Global 
Positioning Satellites). On Sunday, Dewayne Hendricks, WD8DZP, will conduct 
a workshop focusing on a survey of Personal Communications Systems and their 
applications and use in the Amateur Radio Service. Dewayne is an expert in 
the area of commercial wireless systems; his company WarpSpeed Imagineering, 
focuses on wireless Internet. This workshop presents an opportunity to 
learn how Personal Communications Technology (handheld and small business 
wireless systems) can be used in the amateur service. 


Full information on the conference and hotel information can be 
obtained by contacting Tucson Amateur Packet Radio, 8987-309 E. Tanque Verde 
Road, Tucson, AZ 85749-9399. Phone: (817) 383-0000. Fax: (817) 566-2544. 
Internet: TAPR@TAPR.ORG http://www.tapr.org/tapr 


Sincerely, 
Greg Jones, WD5IVD - President, Tucson Amateur Packet Radio 
Dave Wolf, WO5H - President, Texas Packet Radio Society 


From JALOCHA@chopin.ifj.edu.pl Tue Jul 04 06:43:27 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id GAA29640 for 
<hfsig@tapr.org>; Tue, 4 Jul 1995 06:43:20 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFIJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id NAA21826 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Tue, 4 Jul 1995 13:42:17 +0200 

Date: Tue, 4 Jul 1995 13:42 GMT+1 

Subject: Re: [HFSIG:436] Re: HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <9C6FD357C0222014@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>It may be useful to use a Hilbert transform especially if your demodulator 
>require I/Q paths, i.e. doing complex FFT's. You do need, however, some good 
>low pass filters to go with it. All these computational blocks eats at your 
>machine ticks, however. If you can fit it in, that will be excellent. We had 
>some discussion about this topic under "HF channel simulator". 


So I am following this path right now... I did a major redesign so now 
the receiver stages are: 


1. Sampling at 9600 Hz 
2. Bandpass filter 400-2900 Hz (1650+/-1250 Hz), 
sin(x)/x and cos(x)/x parts, complex output 
- is this called the Hilbert transform ? 
3. Downsampling by 3 => makes the sampling rate and bandwidth of 9600/3=3200 Hz 
(I can reduce the sampling rate down to the bandwidth because I analyze 
a complex signal) 
4. Complex numeric oscilator and mixer. 
5. Sliding window + complex FFT (64 points) 
32 points between symbols => 3200/32 = 100 symbols/sec. 
FFT bins are 50 Hz wide, intended carrier spacing is 150 Hz. 


Such design let me do some savings on the FFT CPU cycles 
and storage requirements so the current code is more compact. 


The transmitter stages are very much similar (they go backwards) 
only the oscilator+mixer part is avoided. 
Provision for symbol timing adjustment at the receiver is already there. 


The "band plan": 15 data carriers spaced by 150 Hz. 

First carrier at 600 Hz, last at 2700 Hz. Each carrier is DQPSK modulated 
as 100 baud (2 bits/symbol). Total data rate is 15*100*2=3000 bps. 

Or shall I go to 30 carriers at 50 baud spaced by 75 Hz ? 


I plan to make the modem send some sort of preamble which would enable 
fast tuning and symbol-sync. acquisition. For example send every second 
carrier unmodulated for tuning preamble, then modulate the carriers 

by inverting the phase every symbol for fast symbol-sync. 


The current code (DSPCARD4/EVM56002) contains all the stages I described 

and it seems to work ! Yesterday I made the modem send the preambles 

I described. My expectation is that the modem could auto-tune within +/- 50Hz 
without any loss in performance - what do people think, is that enough ? 


>For interest sake, could you perhaps tell us a bit more about the FREQ4 
>software - where to obtain it etc. These analytical methods and tools are 
>useful to know about. 


A good revision of FFT software was given already on this list. 

I can only confirm that FREQ4 looks very nice, unfortunately 

I don't have an SVGA to run the real nice version :-) 

However one there is one thing I miss in the FREQ4: the spectrum 
averaging feature. There is a "peak" and "decay" display mode but 
that's not really averaging. 


Pawel 
From forrerj@ucs.orst.edu Tue Jul 04 20:28:26 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id UAA03315 for 
<hfsig@tapr.org>; Tue, 4 Jul 1995 20:28:18 -0500 
Received: from p01.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA13889; Tue, 4 Jul 1995 18:28:08 -0700 
Message-Id: <9507050128.AA13889@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 04 Jul 1995 17:39:39 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:443] Re: HFSIG activities 


Pawel, 


>So I am following this path right now... I did a major redesign so now 
>the receiver stages are: 

> 

>1. Sampling at 9600 Hz 

>2. Bandpass filter 400-2900 Hz (1650+/-1250 Hz), 

> sin(x)/x and cos(x)/x parts, complex output 

> - is this called the Hilbert transform ? 


Yes, same filters, just 90 degrees phase shifted. 

>3. Downsampling by 3 => makes the sampling rate and bandwidth of 9600/3=3200 Hz 
> (I can reduce the sampling rate down to the bandwidth because I analyze 
> a complex signal) 

Good idea - you are picking up some processing gain doing this. 

>4. Complex numeric oscilator and mixer. 

I suppose this is to go down to zero IF. 

>5. Sliding window + complex FFT (64 points) 

> 32 points between symbols => 3200/32 = 100 symbols/sec. 

> FFT bins are 50 Hz wide, intended carrier spacing is 150 Hz. 

Sounds quite conservative. 

Your demodulator is beginning to sound much like Adrian's one for Piccolo. 


This very much along the lines I have seen described for several commercial 
designs. You are certainly on the right track! 


>Such design let me do some savings on the FFT CPU cycles 
>and storage requirements so the current code is more compact. 
> 


I'm not sure why this is the result. Could you tell use why? 


>The transmitter stages are very much similar (they go backwards) 

>only the oscilator+mixer part is avoided. 

>Provision for symbol timing adjustment at the receiver is already there. 
> 

>The "band plan": 15 data carriers spaced by 150 Hz. 

>First carrier at 600 Hz, last at 2700 Hz. Each carrier is DQPSK modulated 
>as 100 baud (2 bits/symbol). Total data rate is 15*100*2=3000 bps. 

>Or shall I go to 30 carriers at 50 baud spaced by 75 Hz ? 


This is well worth a try - 100 baud is approaching the upper limit of what 
is feasible due to multipath. If this does not work out as you like, go for 
the the 30 carriers at 50 baud. 


> 

>I plan to make the modem send some sort of preamble which would enable 
>fast tuning and symbol-sync. acquisition. For example send every second 
>carrier unmodulated for tuning preamble, then modulate the carriers 

>by inverting the phase every symbol for fast symbol-sync. 

> 


This is an extensive topic - we can talk about it a lot. Your suggestion 
sounds like a good one - if you can make it work. For such a synchronization 
preamble, some folks use say two tones from your set, choosen as far apart 
as possible, and they are sent for a duration of say 5 baud times. One tone 
is unmodulated and used for doppler estimation and correction. The other 
tone is phase shifted by pi at each baud interval and thus gives you symbol 
synch. It is also common that doppler tone is sent with say double the 
magnitude (6-7dB) than the symbol sync. tone or any of the other carriers 
for that matter. There should be no confusion about it. 


Symbol synch/Doppler estimation may be done several ways - a clever idea is 
to use you sliding FFT demodulator with a pair of tones that alternates 
on/off at the symbol rate. Then estimate your amount of frequency/timing 
error using the following maximum-likelihood estimator for a particular 
timing interval: 


Error = (r2-1r1)/(2(41r1+1r2) ) 


Where r1 and r2 are the Fourier magnitudes of the two alternating tones 
TIMED AT 1/2 the timing interval. For perfect sych. Error=0, and 
Error=+/-0.5 at an offset of 1/2T. The explantion is a little involved to 
expand on but is very elegantly presented in: 


The design of a low data rate MFSK communication system. By Henry D. 
Chadwich and James C. Springett. IEEE Trans. on Communications Tech. VOL: 


COM-18, No.6 (December 1970) pp.740-750. 


>The current code (DSPCARD4/EVM56002) contains all the stages I described 

>and it seems to work ! Yesterday I made the modem send the preambles 

>I described. My expectation is that the modem could auto-tune within +/- 50Hz 
>without any loss in performance - what do people think, is that enough ? 


That is remarkable. Let us know when you are ready with an interim version 
for testing! 


>A good revision of FFT software was given already on this list. 
>I can only confirm that FREQ4 looks very nice, unfortunately 
>I don't have an SVGA to run the real nice version :-) 


What are you missing? The display card or the monitor? I have a card that 
you are welcome to have. 


>However one there is one thing I miss in the FREQ4: the spectrum 
>averaging feature. There is a "peak" and "decay" display mode but 
>that's not really averaging. 

> 


Keep up the good work. Wish I could find more time to join in experiments - 
in a little while I hope thigs will ease up a bit. 


73's 
--Johan, KC7WW 


From JALOCHA@chopin.ifj.edu.pl Wed Jul 05 05:08:07 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id FAAQ7856 for 
<hfsig@tapr.org>; Wed, 5 Jul 1995 05:07:54 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id MAA29192 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Wed, 5 Jul 1995 12:07:05 +0200 

Date: Wed, 5 Jul 1995 12:07 GMT+1 

Subject: Re: [HFSIG:444] Re: HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <584D5BEC4022A761@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>>2. Bandpass filter 400-2900 Hz (1650+/-1250 Hz), 
>> sin(x)/x and cos(x)/x parts, complex output 
>> - is this called the Hilbert transform ? 


> 
>Yes, same filters, just 90 degrees phase shifted. 


A question here: how do I design a good anti-alias filter ? 

good = not too many taps and sufficiant alias band rejection. 

For the moment I calculate it with sin(x)/x * sin(x)*%2 or another window. 
I guess I should get some FIR filters design software. 


>>4. Complex numeric oscilator and mixer. 
> 


>I suppose this is to go down to zero IF. 


Not really (if I understand the topic right) - normally the NCO 
runs at frequency=0 (thus it doesn't affect the signal). 

When I need to tune say up 10 Hz I set the NCO to 10 Hz 

and when I want to tune down 10 Hz I set it to -10 Hz. 


For zero-IF you set the NCO to the center of your passband (1650 Hz) ? 


>>Such design let me do some savings on the FFT CPU cycles 
>>and storage requirements so the current code is more compact. 
>> 

> 

>I'm not sure why this is the result. Could you tell use why? 


The previous design: for 12 tones I had to do a 128 point _real_ FFT. 

I don't have a code for real FFT and I only have one for complex FFT 

(the one taken from the Motorola buletin board). Thus I was doing twice 
the work and after that half of the data was to be put away. 

With the current design I do a 64 point _complex_ FFT for 15 tones 

and all the resulting bins contain usefull information. 

There are some other savings done as well, for example I only store 

the bins I want; before I was storing the whole band for several 

samples "just in case" I need it for re-tuning - many arrays got smaller, 
only the CODEC's buffer stayed huge :-) 


>>The "band plan": 15 data carriers spaced by 150 Hz. 

>>First carrier at 600 Hz, last at 2700 Hz. Each carrier is DQPSK modulated 
>>as 100 baud (2 bits/symbol). Total data rate is 15*100*2=3000 bps. 

>>Or shall I go to 30 carriers at 50 baud spaced by 75 Hz ? 

> 

>This is well worth a try - 100 baud is approaching the upper limit of what 
>is feasible due to multipath. If this does not work out as you like, go for 
>the the 30 carriers at 50 baud. 


This is not a problem for the code, only the mis-tune tolerance 
gets decreased by 2 (+/-25Hz ?) unless you do some clever tricks :-) 


>>I plan to make the modem send some sort of preamble which would enable 
>>fast tuning and symbol-sync. acquisition. For example send every second 
>>carrier unmodulated for tuning preamble, then modulate the carriers 
>>by inverting the phase every symbol for fast symbol-sync. 


> 

>This is an extensive topic - we can talk about it a lot. Your suggestion 
>sounds like a good one - if you can make it work. For such a synchronization 
>preamble, some folks use say two tones from your set, choosen as far apart 
>as possible, and they are sent for a duration of say 5 baud times. One tone 
>is unmodulated and used for doppler estimation and correction. The other 
>tone is phase shifted by pi at each baud interval and thus gives you symbol 
>synch. It is also common that doppler tone is sent with say double the 
>magnitude (6-7dB) than the symbol sync. tone or any of the other carriers 
>for that matter. There should be no confusion about it. 


I like more the idea of many tones. I want to keep the modem resistant 
to CW-type jamming. If I use one tone, and the jamming falls onto it... 


By the way I wonder whether I should keep symbol sync. frozen once 

acquired in the preamble or shall I still follow it during the data phase ? 

If I run my sampling on crystals this seems to be not really needed... 

or there are some jonospheric effects which could "magically" shift the timing ? 
Same thing about tuning correction... 

Anyway, _not_ following the symbol timing would do major code saving: 

I don't need to sample at twice the symbol rate. 

Following the mis-tune doesn't cost much: you only sum up the phase error 

and if you see a constant trend you correct the NCO. 


>Symbol synch/Doppler estimation may be done several ways - a clever idea is 
>to use you sliding FFT demodulator with a pair of tones that alternates 
>on/off at the symbol rate. Then estimate your amount of frequency/timing 
>error using the following maximum-likelihood estimator for a particular 
>timing interval: 

> 

> Error = (r2-1r1)/(2(4r1+1r2) ) 


I don't understand yet, but I will think about it :-) 


My plan was to synchronize on the alternating phase preamble... 
However it would be just simpler to have one common preamble 
to do tune and sync. at same time. The one you suggest may be 
a good candidate. 


>>A good revision of FFT software was given already on this list. 

>>I can only confirm that FREQ4 looks very nice, unfortunately 

>>I don't have an SVGA to run the real nice version :-) 

> 

>What are you missing? The display card or the monitor? I have a card that 
>you are welcome to have. 


My whole PC needs a major upgrade, but I'm going to get a new one 
sooner or later, don't worry :-) 


Pawel 

From paulr@hagar.udc.neweast.ca Wed Jul 05 07:16:25 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA08296 for 


<hfsig@tapr.org>; Wed, 5 Jul 1995 07:15:46 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA25061; Wed, 5 Jul 95 12:15:13 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA804962719; Wed, 05 Jul 95 09:44:47 nst 

Date: Wed, 05 Jul 95 09:44:47 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Message-Id: <9506058049 .AA804962719@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:445] Re: HFSIG activities 


Pawel, 


>>>The "band plan": 15 data carriers spaced by 150 Hz. 

>>First carrier at 600 Hz, last at 2700 Hz. Each carrier is DQPSK modulated 
>>>as 100 baud (2 bits/symbol). Total data rate is 15*100«2=3000 bps. 

>>>Or shall I go to 30 carriers at 50 baud spaced by 75 Hz 

>? > 

>>This is well worth a try - 100 baud is approaching the upper limit of what 
>>is feasible due to multipath. If this does not work out as you like, go for 
>>the the 30 carriers at 50 baud. 

> 

>This is not a problem for the code, only the mis-tune tolerance 

>gets decreased by 2 (+/-25Hz ?) unless you do some clever tricks :-) 


If you use less tones for sync, then you can regain the mis-tune 
tolerance. If the receiver knows which tones to expect, and say 
that you are using 4 of the possible 15 spaced at 200Hz (300Hz?), 
then you get 4* the spacing tolerance: 100Hz (150Hz). If my math 
is reasonable a good balance between jamming resistance and 
mis-tune tolerance can be had by using 1/2, 1/4, or 1/8 or the 
tones during tuning. 


If you use symbol shaping (raised cosine) and alternate the phase 
each symbol, a rectifier feeding a 100Hz Narrow 2nd order (3Hz 
wide) BPF, then a DPLL, will give quick lockon. 


>>>I plan to make the modem send some sort of preamble which would enable 
>>>fast tuning and symbol-sync. acquisition. For example send every second 
>>>carrier unmodulated for tuning preamble, then modulate the carriers 

>>>by inverting the phase every symbol for fast symbol-sync. 

>> 

>>This is an extensive topic - we can talk about it a lot. Your suggestion 
>>sounds like a good one - if you can make it work. For such a synchronization 
>>preamble, some folks use say two tones from your set, choosen as far apart 
>>as possible, and they are sent for a duration of say 5 baud times. One tone 
>>is unmodulated and used for doppler estimation and correction. The other 
>>tone is phase shifted by pi at each baud interval and thus gives you symbol 
>>synch. It is also common that doppler tone is sent with say double the 
>>magnitude (6-7dB) than the symbol sync. tone or any of the other carriers 
>>for that matter. There should be no confusion about it. 


>I like more the idea of many tones. I want to keep the modem resistant 


>to CW-type jamming. If I use one tone, and the jamming falls onto 
SES cs 


>By the way I wonder whether I should keep symbol sync. frozen once 

>acquired in the preamble or shall I still follow it during the data phase ? 
>If I run my sampling on crystals this seems to be not really needed... 

>or there are some jonospheric effects which could "magically" shift the timing 
>? Same thing about tuning correction... 

>Anyway, _not_ following the symbol timing would do major code 

>saving: I don't need to sample at twice the symbol rate. 

>Following the mis-tune doesn't cost much: you only sum up the phase error 

>and if you see a constant trend you correct the NCO. 


Careful of freezing the symbol sync. Crystals are NOT as reliable as you 
think, especially in places varied by temperature (you in death valley and 
your buddy in the Artic <g>). 100ppm (100 parts per million is a common 
error), so 100symbols/sec at 100/1,000,000 = 10,000 symbols before you are 
missalligned by 1 bit (or 5000symbols if 1 end is 100ppm high and the other 
100ppm low). I suspect the modem design could not tolerate more than 2 to 4 
FFT bins of missallignment on a symbol, so 5000 * 1/64 = 78symbols worst 
case, 10000*4/64 = 625 symbols best case. 

So, unless your packets are short, you should run continuous clock 
allignment. One common method is to use wideband and narrow band allignment. 
i.e. allow wide clock adjustment during sync up (8/64 per symbol), and only a 
small allignment during packet reception (1/64 per symbol, or even fractional 
adjusts of say (1/4)/64 (-4 in a row to high/low before correct by 1 clock 
tick). 


Tuning tolerance is probably similiar. I suspect that unless you are in a jet 
doing fast turns towards and away from the source, you will have very minor 
doppler (due to ionosphere layer movements, ox during the switch from one 
path to another path in multipath). If your CPU can handle it, set it to 
track at probably between @.1Hz and 1 Hz/symbol (arbitrary values, sorry no 
test data). 


So if you can course tune on a limited tone preamble: adjust for >50HzZ error 
to < 10Hz error (Adjust limited to 1/2 the spacing between tones present). 
Then fine tune during the end of the preamble and during the data (adjust 
limited by 1/2 the tone spacing). This would indeed be a nice system. I 
suspect my company (Ultimateast, 709-576-4747, ask for Dwight Howell or John 
Mackey, say Paul Russell referred you) would definitely consider buying an 
implementation (I'm moving to a new job and won't be here to do it myself). 


Paul Russell 
paulr@neweast.ca (for this and next week) 


From JALOCHA@chopin.ifj.edu.pl Wed Jul 05 08:46:00 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA09187 for 
<hfsig@tapr.org>; Wed, 5 Jul 1995 08:45:52 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id PAA@1755 for <@NMS.CYF- 


KR.EDU.PL:hfsig@tapr.org>; Wed, 5 Jul 1995 15:45:00 +0200 
Date: Wed, 5 Jul 1995 15:44 GMT+1 

Subject: Re: [HFSIG:446] Re: HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <76B89AC62022A761@chopin.ifj.edu.pl> 
X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 
X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>If you use less tones for sync, then you can regain the mis-tune 
>tolerance. 


Yes, I had this in mind... 


>If the receiver knows which tones to expect, and say 

>that you are using 4 of the possible 15 spaced at 200Hz (300Hz?), 
>then you get 4x the spacing tolerance: 100Hz (150Hz). If my math 
>is reasonable a good balance between jamming resistance and 
>mis-tune tolerance can be had by using 1/2, 1/4, or 1/8 or the 
>tones during tuning. 


1/4 is better than 1/2 and 1/8 for one "trivial" reason: 

if you want to keep same RMS while transmitting 1/4th of the tones 
you should increase the tone's amplitudes by a factor of 2. 

For 1/2 or 1/8 this factor becomes a bit more ugly :-) 


For the moment I put in 4 "tuning" tones: 750, 1350, 1950, 2550 Hz 

(600 Hz spacing). Thus is principle I could have +/-300Hz tuning tolerance. 
But... my passband is not that wide. I would need to make more "spare" 
bandwidth in the transceiver audio. This is another issue to discuss: 

I am trying to fit it 2500 Hz of usefull spectrum. Isn't it too much ? 

We could as well use only 2000 Hz with 16 tones (like one military standard 
does) and leave 200-300 Hz on both sides for tuning corrections 

and equipment imperfections ? 


>If you use symbol shaping (raised cosine) and alternate the phase 
>each symbol, a rectifier feeding a 100Hz Narrow 2nd order (3Hz 
>wide) BPF, then a DPLL, will give quick lockon. 


You mean avoiding the FFT and putting the time-domain samples straight 
into the rectifier. This might not be as good as looking at selected 
tones after the FFT (jamming resistance again) but it's a good idea. 


>So, unless your packets are short, you should run continuous clock 
>allignment. One common method is to use wideband and narrow band allignment. 
>i.e. allow wide clock adjustment during sync up (8/64 per symbol), and only a 
>small allignment during packet reception (1/64 per symbol, or even fractional 
>adjusts of say (1/4)/64 (-4 in a row to high/low before correct by 1 clock 
>tick). 


OK. I will run a slow clock adjustment during the data phase. 
I was taking a very optimistic 10E-5 crystal stability for my calculations :-) 
but if they can be 10E-4... 


>Tuning tolerance is probably similiar. I suspect that unless you are in a jet 
>doing fast turns towards and away from the source, you will have very minor 
>doppler (due to ionosphere layer movements, or during the switch from one 
>path to another path in multipath). If your CPU can handle it, set it to 
>track at probably between ©.1Hz and 1 Hz/symbol (arbitrary values, sorry no 
>test data). 


Infact for the Doppler shift I was afraid more of transceiver's 
instabilities... but I should do a slow adjustments anyway. 
General conclusion: do both adjustments all the time ! 


>So if you can course tune on a limited tone preamble: adjust for >50HzZ error 
>to < 10Hz error (Adjust limited to 1/2 the spacing between tones present). 
>Then fine tune during the end of the preamble and during the data (adjust 
>limited by 1/2 the tone spacing). This would indeed be a nice system. 


I had in mind coarse tuning adjustment during the tuning preamble 

and when the symbol sync. preamble comes, I could refine the tuning 

while doing symbol sync. - this is not much a problem. 

I suspect this will be the major problem (at least for me) to make the code 
do all these things at the right time :-) Tuning, symbol sync., data coding 
I know how to do in principle... 


>I suspect my company (Ultimateast, 709-576-4747, ask for Dwight Howell or John 
>Mackey, say Paul Russell referred you) would definitely consider buying an 
>implementation (I'm moving to a new job and won't be here to do it myself). 


And what happens when I sell the implementation ? Would it be still 
available to amateur radio ? :-) 


Pawel 

From paulr@hagar.udc.neweast.ca Thu Jul 06 08:36:22 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id IAA23159 for 

<hfsig@tapr.org>; Thu, 6 Jul 1995 08:36:15 -0500 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AAQQ032; Thu, 6 Jul 95 13:36:11 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA805053979; Thu, 06 Jul 95 11:06:04 nst 

Date: Thu, 06 Jul 95 11:06:04 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Message-Id: <9506068050.AA805053979@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:447] Re: HFSIG activities 


>1/4 is better than 1/2 and 1/8 for one "trivial" reason: 

>if you want to keep same RMS while transmitting 1/4th of the tones 
>you should increase the tone's amplitudes by a factor of 2. 

>For 1/2 or 1/8 this factor becomes a bit more ugly :-) 


Note: The individual phase sets for each tone don't have to use 
the same reference in DPSK. 


so Tone 1 could use 10, 100, 190, 280 QDPSK 

tone 2 could use 350, 80, 170, 260 
etc. 
An optimization program (weeks of background processing time) can 
be written (did something similar for a 4 channel FSK) that will 
try to optimize a good reference for each tone phase set. You 
have to calculate the worst superposition of the output symbol 
for all possible tone phase combinations, while varying each 
starting tone phase reference by 1 sample in the tone generator. 
When done you can gain upto a factor of 2 on a peak to average 
signal amplitude (4* power). 


As long as each set of phases for each tone is ok (DBPSK @180, DQPSK @90, 8 @ 
45...) the sets can have independent offsets, and there are combinations of 
offsets for a tone set that will minimize the peak for the whole symbol set by a 
factor of about 2:1. 


>For the moment I put in 4 "tuning" tones: 750, 1350, 1950, 2550 Hz 

>(600 Hz spacing). Thus is principle I could have +/-300Hz tuning tolerance. 
>But... my passband is not that wide. I would need to make more "spare" 
>bandwidth in the transceiver audio. This is another issue to discuss: 

>I am trying to fit it 2500 Hz of useful spectrum. Isn't it too much ? 

>We could as well use only 2000 Hz with 16 tones (like one military standard 
>does) and leave 200-300 Hz on both sides for tuning corrections 

>and equipment imperfections ? 


I would definitely recommend going to a narrower minimum 
requirement, not all Hams may have radios with nice passbands and 
the more general the design the more potential users. Best radio 
I've seen (300-2750Hz) worst (450-2550), so in my experience if 
you only use about (550-2550) it might be best. Or if a protocol 
can be configured to test and drop/ignore the outside tones in 
some connections (like a Trailblaser telephone modem does). Tones 
dropped figured during link setup or by pre-programming? Maybe 
the initial call done using a subset (1000-2000Hz only) then 
after contact eval exactly how wide is available? I know this is 
costly in development time, but it may pay off later in easier 
use. 


>>If you use symbol shaping (raised cosine) and alternate the phase 
>>each symbol, a rectifier feeding a 100Hz Narrow 2nd order (3Hz 
>>wide) BPF, then a DPLL, will give quick lockon. 

> 

>You mean avoiding the FFT and putting the time-domain samples straight 
>into the rectifier. This might not be as good as looking at selected 
>tones after the FFT (jamming resistance again) but it's a good idea. 


Constant tone jamming or slow fading falls out as you are only 
tracking the average AC component of the signal power at the BPF. 
Jamming with a pulsing signal at near the baud rate would still 
be a problem, but random data transmitted over the signal in 
Similiar modulation will confuse almost everything except maybe 
spread spectrum. 


>And what happens when I sell the implementation ? Would it be still 
>available to amateur radio ? :-) 


Depends on how you wrote the contract (so yes). This company puts 
most of the propiatary stuff in the protocols, channel 
evaluation, and interconnection to other systems, instead of the 
modulation anyway. Just a thought, can't say at this point 
whether it would be worth the effort. But if you do have 
something in say 6 months give them a call... 


Pawel 


From gjones@tenet.edu Sat Jul 08 09:38:37 1995 

Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) 

by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id JAA17950; Sat, 8 Jul 

1995 09:38:28 -0500 

Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id 

JAA23566; Sat, 8 Jul 1995 09:38:27 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199507081438.JAA23566@Leslie-Francis.tenet.edu> 

Subject: mail_archive 

To: bbssig@tapr.org (BBS SIG mailing), netsig@tapr.org (NETSIG mailing), 
hfsig@tapr.org (HF SIG mailing), aprssig@tapr.org (BBS SIG mailing) 

Date: Sat, 8 Jul 1995 09:38:26 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 329 


The mail archives for all the SIGs are now updated nightly. 
They can be gotten by ftp in each SIG area under mail_archive 
ftp://ftp.tapr.org/tapr/SIG/ 


In addition, the mail_archive files have been available from the TAPR 
listserv. 


There are links to the SIGs in the TAPR web page. 
http: //www.tapr.org/tapr 


Cheers - Greg 
From frode@dxcern.cern.ch Mon Jul 10 09:52:43 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA16217 for 
<hfsig@tapr.org>; Mon, 10 Jul 1995 09:52:24 -0500 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AA28839; Mon, 10 Jul 1995 16:52:20 +0200 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AAQ4406; Mon, 10 Jul 1995 16:52:19 +0200 
Date: Mon, 10 Jul 1995 16:52:19 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 


To: HFSIG TAPR <hfsig@tapr.org> 

Subject: ANDVT TACTERM Documentation 

Message-Id: <Pine.ULT.3.91.950710154436 .14265A-100000@dxcern.cern.ch> 
Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi all, 


To keep the subject on multitone modems hot and as an aid in cracking 
open the outstanding problems on Pawel's multitone design like 
synchronization and error correction coding I have the following minor 
contributions to make. 


I have been reading up on what the commercial and military users have 
done and are doing in the multitone field and I just uploaded a ZIP 
archive on TAPR's FTP server (ftp.tapr.org) in the HFSIG upload 
directory: /tapr/SIG/hfsig/upload with some information on the protocols 
used in the ANDVT TACTERM AND AN/USQ-83(V) modems. 


The archive is called andvt.zip and here is the contents of the andvt.txt 
file: 


This archive contains a total of three files. 


- readme Which you are reading now 
- andvt.asc ASCII version of The Variable Speed HF Modem 
- andvt.doc WORD 5.5 version of The Variable Speed HF Modem 


If any of the two files andvt.asc and andvt.doc are distributed ina 
different format than the present ZIP archive, please make sure to include 
this readme file. 


The documentation of The Variable Speed HF Modem (VSM) has been extracted 
almost verbatim from David L. Tate's report "The Variable Speed HF Modem, 
Modulator Design". NRL Report 9169, March 20, 1989; NTIS Report No.: 
AD-A244 891. The parts extracted concerns mainly the description of the 
protocols used by the ANDVT TACTERM AND AN/USQ-83(V) modems, hence the file 
names andvt.asc and andvt.doc. 


This writeup on the VSM has been made by Frode Weierud, LA2RL, with the 
authorisation of the original author David Tate. On the question of 
copyright etc. David Tate have instructed me as follows: 


Dear Mr. Weierud, 

The report titled "The Variable Speed HF Modem Modulator Design" is not 
copyrighted and you are free to distribute any portion of it as you wish. 
If you include any of it in any published report, I would ask that you 


reference it as a professional courtesy. 


- David Tate 


Therefore the two documents andvt.asc and andvt.doc are also free of any 
copyrights, but I insist that the original author's request for proper 
referencing is adhered to also in the case of information taken from my two 
documents andvt.asc and andvt.doc. 


Frode Weierud, LA2RL 
E-mail : frode@dxcern.cern.ch 


I hope some of you might get some good ideas about how to handle the 
symbol and bit synchronization in our multitone modem when seeing how it 
is done in the ANDVT TACTERM modem. 


Another issue that surely will come up later is error correction coding. 
I have recently re-read a paper that deals with this and which I find is 
well written and gives a lot of useful information on error correction 

codes used with parallel and serial tone modems on HF. The reference is: 


P.G. Farrell and R.M.F Goodman, "Soft-decision error control for 
h.£. data transmission", IEE Proc., Vol. 127, Part F, No.5, 

Oct. 1980. (NB! This is the English Institute of Electrical 
Engineers) 


73's Frode, LA2RL 


Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From k5yfw@sacdm10.kelly.af.mil Mon Jul 10 21:16:35 1995 
Received: from sacdmi0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id VAA30230 for 
<hfsig@tapr.org>; Mon, 10 Jul 1995 21:16:29 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsVUng-0002EZC; Mon, 10 Jul 95 21:11 CDT 
Message-Id: <mOsVUng-Q002EZC@sacdm10.kelly.af.mil> 
Date: Mon, 10 Jul 95 21:11:51 -0500 
From: k5yf£w@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:450] ANDVT TACTERM Documentation 
To: hfsig@tapr.org 
X-orig-date: Mon, 10 Jul 1995 10:07:11 -0500 
X-orig-from: Frode Weierud <frode@dxcern.cern.ch> 
X-orig-message-ID: <Pine.ULT.3.91.950710154436 .14265A-100000@dxcern.cern.ch> 


In Frode's message of 10 Jul 1995 at 1007 CDT, he writes: 

To keep the subject on multitone modems hot and as an aid in cracking 
open the outstanding problems on Pawel's multitone design like 
synchronization and error correction coding I have the following minor 
contributions to make. 


VV VV VV 


I have been reading up on what the commercial and military users have 


done and are doing in the multitone field and I just uploaded a ZIP 
archive on TAPR's FTP server (ftp.tapr.org) in the HFSIG upload 
directory: /tapr/SIG/hfsig/upload with some information on the protocols 
used in the ANDVT TACTERM AND AN/USQ-83(V) modems. 


VVV Vv 


The ANDVT TACTERM is of rather old design and I believe was the first 
implementation of the 39 parallel tone modem of MIL-STD-188-110A. If 
my memory serves me correctly, the TACTERM is over 10 years old. 


For any who read about this device, on voice operation the modem is 
the MIL-STD 39 tone modem with all the FEC, etc features of the 
MIL-STD turned on. On data, the modem uses the MIL-STD 16 tone modem 
format which does *xnot*x have FEC. Both modems run at 2400 BPS on HF. 


I used the TACTERM on HF data at 2400 BPS (and voice) before and 
during Desert Shield/Storm and it beats the pants off of 110 baud (and 
300 baud) ASCII, packet, AMTOR and the like...and that is without FEC. 
I can just imagine what the 16 tone modem would do with a little FEC. 


This would be a good model to duplicate using DSP and a soundcard as 
a first effort in getting high speed data on HF. 


Walt 

From JALOCHA@chopin.ifj.edu.pl Wed Jul 12 04:59:13 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id EAA20877 for 
<hfsig@tapr.org>; Wed, 12 Jul 1995 04:59:05 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id LAA25591 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Wed, 12 Jul 1995 11:58:16 +0200 

Date: Wed, 12 Jul 1995 11:58 GMT+1 

Subject: Re: [HFSIG:451] Re: ANDVT TACTERM Documentation 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <D73B85306022A758@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>I used the TACTERM on HF data at 2400 BPS (and voice) before and 
>during Desert Shield/Storm and it beats the pants off of 110 baud (and 
>300 baud) ASCII, packet, AMTOR and the like...and that is without FEC. 


You mean TACTERM beats other protocols in the sense of data rate 
or better performance in weak propagation conditions ? 


>This would be a good model to duplicate using DSP and a soundcard as 
>a first effort in getting high speed data on HF. 


I am on a very close track actually, if I change decimation ratio 
in my design from 3 to 4 I get exactly the tone spacing and symbol rate 
used by TACTERM. 


One interresting detail of TACTERM I noticed: the tune-in preamble 


uses tones from outside the data band... and I don't see a good 
reason for this. Why send two tones where you are not going to send 
any data ? I would rather filter out this part of audio. 


Progress report on my code - as it is now it does the following: 


TX: 

- sends four tuning tones for 32 symbols (0.32 second). 

- modulates the tuning tones by alternating the phase for 32 symbols. 
This is for the receiver to get symbol-sync. 

- switches to 15 tones and sends 100 "random" symbols. 

- sends 16 symbols of jamming data so the receiver's DCD switches off 
quickly. 


- Listens and waits for the tuning tones. 
When found and present for some minimal time the Rx finds out 
the freq. error and switches to sync. wait mode. 

- Waits until the tones become bi-modulated in phase. 
If they don't within some timeout the Rx goes back to "listen for tune" mode. 
If they do, and stay modulated for some minimal time, the Rx finds out 
the symbol timing, freq. error and switched to data mode. This part is 
not yet all done and is right now under developement. 

- Next, the Rx should receive the data, and do little freq. and symbol-sync. 
adjustments while monitoring the DCD condition. When DCD drops, the Rx 
switches to "listen for tune". 


Pawel 
From claude@bauv106.bauv.unibw-muenchen.de Wed Jul 12 06:22:54 1995 
Received: from gatesrv.rz.unibw-muenchen.de (gatesrv.RZ.UniBw-Muenchen.de 
[137.193.10.21]) by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id GAA21461 
for <hfsig@tapr.org>; Wed, 12 Jul 1995 06:22:34 -0500 
Received: from bauv106.BauV.UniBw-Muenchen.de by gatesrv.rz.unibw-muenchen.de with 
SMTP id AA17548 
(5.65c+/IDA-1.4.4 for tapr.org); Wed, 12 Jul 1995 13:22:34 +0200 
Received: (4.1/0.008ycf) 
by bauv106.bauv.unibw-muenchen.de (for hfsig@tapr.org) id AAQOQ417; Wed, 12 
Jul 95 13:02:19 +0200 
From: claude@bauv106.bauv.unibw-muenchen.de (Claude Frantz) 
Message-Id: <9507121102 .AAQ00417@bauv106.bauv.unibw-muenchen.de> 
Subject: Re: [HFSIG:451] Re: ANDVT TACTERM Documentation 
To: hfsig@tapr.org 
Date: Wed, 12 Jul 95 13:02:18 MET DST 
In-Reply-To: <mOsVUng-0002EZC@sacdm10.kelly.af.mil>; from "WALT DUBOSE - K5YFW" at 
Jul 10, 95 9:25 pm 
Errors-To: claude@bauv106.bauv.unibw-muenchen.de 
X-Mailer: ELM [version 2.3 PL11] 


According to WALT DUBOSE - K5YFW: 
> I used the TACTERM on HF data at 2400 BPS (and voice) before and 


> during Desert Shield/Storm and it beats the pants off of 110 baud (and 
> 300 baud) ASCII, packet, AMTOR and the like...and that is without FEC. 


> I can just imagine what the 16 tone modem would do with a little FEC. 


> This would be a good model to duplicate using DSP and a soundcard as 
> a first effort in getting high speed data on HF. 


Have you any information about the technology used by this TACTERM 
(hardware, software) ? 


Claude 
From frode@dxcern.cern.ch Wed Jul 12 07:24:48 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA21879 for 
<hfsig@tapr.org>; Wed, 12 Jul 1995 07:24:43 -0500 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AA18547; Wed, 12 Jul 1995 14:24:39 +0200 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA19334; Wed, 12 Jul 1995 14:24:39 +0200 
Date: Wed, 12 Jul 1995 14:24:38 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:452] Re: ANDVT TACTERM Documentation 
In-Reply-To: <D73B85306022A758@chopin.ifj.edu.pl> 
Message-Id: <Pine.ULT.3.91.950712140350 .9690B-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 12 Jul 1995 JALOCHA@chopin.ifj.edu.pl wrote: 


I am on a very close track actually, if I change decimation ratio 
in my design from 3 to 4 I get exactly the tone spacing and symbol rate 
used by TACTERM. 


One interresting detail of TACTERM I noticed: the tune-in preamble 
uses tones from outside the data band... and I don't see a good 
reason for this. Why send two tones where you are not going to send 
any data ? I would rather filter out this part of audio. 


VV VVV VV VV MV 


I wonder if it could be implementation related. The HF radio will have a 
300 - 3000Hz IF bandwith so the four Doppler tones will fit OK in this 
bandwith. The two middle tones used for tuning (Doppler tones) 

correspond to data tone No. 6 and No.12 (1462.5 Hz and 2137.5 Hz). The 
distance between the two tones is 675 Hz, which is the distance between all 
the four Doppler tones. 675 Hz is also the distance between the three 

frame sync tones, which correspond to data tones No. 3, 9 and 15. This 
distance of 675 Hz is 6 times the data tone distance which is 112.5 Hz. 


I therefore suppose that they wanted to have a different set of tones for 
Doppler preamble and frame preamble, but that they wanted to keep the 
same bin distance of 675 Hz. The symmetrical selection of these tones 
with respect to the data tones then means two of the Doppler tones will 
fall slightly outside the boundary of the data tone set. 


Pawel, congratulation with the tremendous progress on your parallel tone 
modem. I am curious to see what will happen when you modulate a SSB rig 
with this waveform. As Paul, I am somewhat afraid we will run into 
problems with the IF bandwith of most HAM rigs. I just read a review of 
the ICOM IC-736 HF rig yesterday, where they proudly announce very steep 
IF filters with 2.1 kHz bandwith, exactly what we don't want, :-) 


I know this is not a real problem, but I am afraid we probably will have 
to reduce the number of tones to be sure to fit nicely within a 2.1 kHz 
IF bandwith. 


73's Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From JALOCHA@chopin.ifj.edu.pl Wed Jul 12 08:14:59 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id IAA22767 for 
<hfsig@tapr.org>; Wed, 12 Jul 1995 08:14:27 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id PAA28083 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Wed, 12 Jul 1995 15:13:24 +0200 

Date: Wed, 12 Jul 1995 15:13 GMT+1 

Subject: Re: [HFSIG:454] Re: ANDVT TACTERM Documentation 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <F2734C1AC022A758@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


>I am curious to see what will happen when you modulate a SSB rig 

>with this waveform. As Paul, I am somewhat afraid we will run into 
>problems with the IF bandwith of most HAM rigs. I just read a review of 
>the ICOM IC-736 HF rig yesterday, where they proudly announce very steep 
>IF filters with 2.1 kHz bandwith, exactly what we don't want, :-) 


Did they say where are the audio band edges ? 

Why don't they make a rig with 1 kHz bandwidth ? :-) 

Actually it's easier to make a narrow crystal filter than a wide one. 
But maybe the IC-738 filter's width is still switchable ? 

I know there are rigs with 1.8 kHz bandwidth... if we want to keep 
compatibility with these, we have to squeeze the tones even more. 


>I know this is not a real problem, but I am afraid we probably will have 
>to reduce the number of tones to be sure to fit nicely within a 2.1 kHz 
>IF bandwith. 


I expect this to be a rather minor operation. 
I would rather stay with 16 tones but reduce the spacing to 112.5 Hz 
and the baud rate to 75 - are here we came to TACTERM :-) 


16 is a nice number for FEC-codes... like Walsh functions. 
Later we can try 32 tones with 37.5 baud each. 


By the way is there an optimal symbol rate for HF and DQPSK ? 
If too high, the multi-paths come into effect, 

if too low, the phase incoherency affects the data... 

so where is the optimum ? 


Pawel 
From k5yfw@sacdm10.kelly.af.mil Wed Jul 12 23:54:19 1995 
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id XAA05468 for 
<hfsig@tapr.org>; Wed, 12 Jul 1995 23:54:12 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsWGDL-0002G1C; Wed, 12 Jul 95 23:49 CDT 
Message-Id: <mOsWGDL-0002G1C@sacdm10.kelly.af.mil> 
Date: Wed, 12 Jul 95 23:49:30 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:452] Re: ANDVT TACTERM Documentation 
To: hfsig@tapr.org 
X-orig-date: Wed, 12 Jul 1995 05:01:33 -0500 
X-orig-from: JALOCHA@chopin.ifj.edu.pl 
X-orig-message-ID: <D73B85306022A758@chopin.ifj.edu.pl> 


In Pawel's message of 12 Jul 1995 at 0501 CDT, he writes: 

>I used the TACTERM on HF data at 2400 BPS (and voice) before and 
>during Desert Shield/Storm and it beats the pants off of 110 baud (and 
>300 baud) ASCII, packet, AMTOR and the like...and that is without FEC. 


You mean TACTERM beats other protocols in the sense of data rate 
or better performance in weak propagation conditions ? 


VVVVV Vv 


We had a 300 baud Bell 102 modem device (terminal) and 
PK-232s and other Military modems for 50/100/110/300 baud... 
running RATT, ASCII, AX.25, AMTOR. 


2400 BPS was faster than the others and had acceptable 
thruput during poor signal conditions. In poor conditions we 
got near 2400 BPS thruput vs no thruput with the 110/300 baud 
modems/protocols. AMTOR/SITOR worked as well as the TACTERM 
in poor conditions but the thruput of AMTOR/SITOR was no 
comparison. 


I didn't try the TACTERM an any bit rate less than 2400... 
maybe 1200 once. 


>This would be a good model to duplicate using DSP and a soundcard as 
>a first effort in getting high speed data on HF. 


I am on a very close track actually, if I change decimation ratio 
in my design from 3 to 4 I get exactly the tone spacing and symbol rate 
used by TACTERM. 


VV VV VV MV 


One interresting detail of TACTERM I noticed: the tune-in preamble 
uses tones from outside the data band... and I don't see a good 
reason for this. Why send two tones where you are not going to send 
any data ? I would rather filter out this part of audio. 


VV VV NV 


Good show. I'm sure that the 10+ years of technology since 
the TACTERM was designed/produced should all for improvements 
in the modem protocol. I do feel that any new modem protocol 
should include FEC. 


If I remember correctly, 2400 BPS is the thruput rate but the 
modulation bit rate is 3100 BPS on the 39 tone...about 1/3 of 
the data is for the FEC. What would FEC do to a 16 tone 
modem? 


Progress report on my code - as it is now it does the following: 


TX: 

- sends four tuning tones for 32 symbols (0.32 second). 

- modulates the tuning tones by alternating the phase for 32 symbols. 
This is for the receiver to get symbol-sync. 

- switches to 15 tones and sends 100 "random" symbols. 

- sends 16 symbols of jamming data so the receiver's DCD switches off 
quickly. 


Rx: 

- Listens and waits for the tuning tones. 
When found and present for some minimal time the Rx finds out 
the freq. error and switches to sync. wait mode. 

- Waits until the tones become bi-modulated in phase. 
If they don't within some timeout the Rx goes back to "listen for tune" mode. 
If they do, and stay modulated for some minimal time, the Rx finds out 
the symbol timing, freq. error and switched to data mode. This part is 
not yet all done and is right now under developement. 

- Next, the Rx should receive the data, and do little freq. and symbol-sync. 
adjustments while monitoring the DCD condition. When DCD drops, the Rx 
switches to "listen for tune". 


Pawel 


VV VV VV VV VV VV VV VV VV VV VV VV VV 


73 All, Walt 
From k5yfw@sacdm10.kelly.af.mil Wed Jul 12 23:56:09 1995 
Received: from sacdm1i0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id XAA05490 for 
<hfsig@tapr.org>; Wed, 12 Jul 1995 23:56:03 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsWGFA-0002G1C; Wed, 12 Jul 95 23:51 CDT 
Message-Id: <mOsWGFA-0002G1C@sacdm10.kelly.af.mil> 


Date: Wed, 12 Jul 95 23:51:24 -0500 

From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 

Subject: Re: [HFSIG:453] Re: ANDVT TACTERM Documentation 

To: hfsig@tapr.org 

X-orig-date: Wed, 12 Jul 1995 06:33:22 -0500 

X-orig-from: claude@bauv106.bauv.unibw-muenchen.de (Claude Frantz) 
X-orig-message-ID: <9507121102 .AAQ00417@bauv106.bauv.unibw-muenchen.de> 


The 16 & 39 tone modems are described in U.S. MIL-STD-188-110A. I 
loaned out my copy but several individuals on the group have copies. 


Walt 


In your message of 12 Jul 1995 at 0633 CDT, you write: 


> According to WALT DUBOSE - K5YFW: 

> 

> > I used the TACTERM on HF data at 2400 BPS (and voice) before and 

> > during Desert Shield/Storm and it beats the pants off of 110 baud (and 
> > 300 baud) ASCII, packet, AMTOR and the like...and that is without FEC. 
> > I can just imagine what the 16 tone modem would do with a little FEC. 
> 

> > This would be a good model to duplicate using DSP and a soundcard as 

> > a first effort in getting high speed data on HF. 

> 

> Have you any information about the technology used by this TACTERM 

> (hardware, software) ? 

> 

> Claude 

> 


From frode@dxcern.cern.ch Thu Jul 13 02:23:15 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id CAA07978 for 
<hfsig@tapr.org>; Thu, 13 Jul 1995 02:23:11 -0500 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AA26244; Thu, 13 Jul 1995 09:23:09 +0200 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AAQ1299; Thu, 13 Jul 1995 09:23:07 +0200 
Date: Thu, 13 Jul 1995 09:23:07 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:455] Re: ANDVT TACTERM Documentation 
In-Reply-To: <F2734C1ACO22A758@chopin.ifj.edu.pl> 
Message-Id: <Pine.ULT.3.91.950713085413 .29937A-100000@dxcern.cexrn.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 12 Jul 1995 JALOCHA@chopin.ifj.edu.pl wrote: 


Did they say where are the audio band edges ? 

Why don't they make a rig with 1 kHz bandwidth ? :-) 

Actually it's easier to make a narrow crystal filter than a wide one. 
But maybe the IC-738 filter's width is still switchable ? 


VV VV WV 


The IF/audio bandwidth measured on a IC-736 transceiver in the ARRL lab 
is as follows at the - 6 dB points: 

USB: 401 - 2102 Hz (1701 Hz) 

LSB: 431 - 2148 Hz (1717 Hz) 


So as you can see rather narrow. The radio has passband tuning and a 
position for fitting a second smaller filter. Usually a 500 Hz filter is 
fitted in the two IFs (9 MHz and 455 MHz). 


On the other hand most of the military radios have an IF/audio bandwidth 
of 300 - 3000 Hz at the -3db points, with a group delay variation of 
+-0.5 ms between 800 - 2800 Hz. I think no HAM tranceiver can match this. 


> 

>By the way is there an optimal symbol rate for HF and DQPSK ? 
> If too high, the multi-paths come into effect, 

> if too low, the phase incoherency affects the data... 

> so where is the optimum ? 


Pawel is always asking difficult questions, :-) 

It is clear there is an optimum rate at a given moment and for given 
propagation conditions, the only problem is that the propagation varies 

all the time. I have seen a study made by the Swedish Defence 

establishment that tested FSK modulation rates between 37 Baud and 600 Baud. 
They found that you even could run happily at 600 Bauds from time to 

time, specially during day time on a good day time frequency. One thing 

to keep in mind when reading such studies is that the military usually 

work with links between 100 - 1000 km, so there is no real DX involved, :-) 


>From what I have read so far I think 75 Baud is a very conservative rate 
which undoubtedly will work under almost all conditions. Personally I 
think the optimal, safe rate is closer to 125 Baud. As far as I have 
understood it should also be safer to run 125 Baud DQPSK than 125 Baud 
FSK, but this might again depend on the design of the FSK demodulator. 


I have seen a reference to one modem using 66 tones with 37.5 Baud. I 
can't quite remember what waveform it used, but I think it was DPSK. 
Personally I think I would use less tones and a higher symbol rate. 


73's Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From SONNTAG@vaxa.acdnj.itt.com Thu Jul 13 09:38:51 1995 

Received: from vaxa.acdnj.itt.com (vaxa.acdnj.itt.com [151.190.1.3]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id JAA10865 for 
<hfsig@tapr.org>; Thu, 13 Jul 1995 09:38:46 -0500 

From: SONNTAG@vaxa.acdnj.itt.com 

Message-Id: <199507131438.JAA10865@dingus.n5lyt.datarace.com> 


Date: 13 Jul 95 10:33:00 EST 
Subject: address 
To: "hfsig" <hfsig@tapr.org> 


For some reason my address has spontaineously changed to an incorrect address. 
Please 
change "Snntag@... to "Sonntag@...". 


Thanks! 


From gjones@tenet.edu Thu Jul 13 10:40:48 1995 

Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) 
by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id KAA11776; Thu, 13 Jul 
1995 10:40:42 -0500 

Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id 
KAAQ1205; Thu, 13 Jul 1995 10:40:37 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199507131540.KAAQ1205@Leslie-Francis.tenet.edu> 

Subject: Re: [HFSIG:459] address 

To: hfsig@tapr.org 

Date: Thu, 13 Jul 1995 10:40:36 -0500 (CDT) 

Cc: n5lyt@dingus.n5lyt.datarace.com (Lee Ziegenhals) 

In-Reply-To: <199507131438.JAA10865@dingus.n5lyt.datarace.com> from 
"SONNTAG@vaxa.acdnj.itt.com" at Jul 13, 95 09:42:21 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 324 


I am sorry, but on the listserv you are listed as: SONNTAG@VAXA.ACDNJ.ITT.COM 
Your problem might be elsewhere. 
Cheers - Greg 


According to SONNTAG@vaxa.acdnj.itt.com: 

> 

> For some reason my address has spontaineously changed to an incorrect address. 
Please 

> change "Snntag@... to "Sonntag@...". 

> 
> Thanks! 
> 

> 


From chbrain@dircon.co.uk Thu Jul 13 13:13:20 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id NAA14530 for 

<hfsig@tapr.org>; Thu, 13 Jul 1995 13:13:10 -0500 

Received: by felix.dircon.co.uk id AA24625 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 13 Jul 1995 19:12:07 +0100 

Message-Id: <199507131812.AA24625@felix.dircon.co.uk> 

Received: from ac045.pool.dircon.co.uk(193.128.230.45) by amnesiac via smap (V1.3) 
id sma024601; Thu Jul 13 19:11:37 1995 


X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 13 Jul 1995 17:21:51 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Hilbert 


Here is a question for the group, 


If one implements a Hilbert Transform using a FIR filter and the 
Parks Mc Clelland algorithm which sample in the input buffer is the 
one that is 90 deg phase different? is it the one in the middle? 


Regards Confused! 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From k5yfw@sacdm10.kelly.af.mil Thu Jul 13 18:23:26 1995 
Received: from sacdmi0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id SAA19639 for 
<hfsig@tapr.org>; Thu, 13 Jul 1995 18:23:20 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsWXWh-Q002FEC; Thu, 13 Jul 95 18:18 CDT 
Message-Id: <mOswWXWh-Q002FEC@sacdm10.kelly.af.mil> 
Date: Thu, 13 Jul 95 18:18:39 -0500 
From: k5yfw@sacdm10.kelly.af£.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:458] Re: ANDVT TACTERM Documentation 
To: hfsig@tapr.org 
X-orig-date: Thu, 13 Jul 1995 02:30:11 -0500 
X-orig-from: Frode Weierud <frode@dxcern.cern.ch> 
X-orig-message-ID: <Pine.ULT.3.91.950713085413 .29937A-100000@dxcern.cern.ch> 


In Frode's message of 13 Jul 1995 at 0230 CDT, he writes: 
On Wed, 12 Jul 1995 JALOCHA@chopin.ifj.edu.pl wrote: 


> 
> Did they say where are the audio band edges ? 

> Why don't they make a rig with 1 kHz bandwidth ? :-) 

> Actually it's easier to make a narrow crystal filter than a wide one. 
> But maybe the IC-738 filter's width is still switchable ? 


The IF/audio bandwidth measured on a IC-736 transceiver in the ARRL lab 
is as follows at the - 6 dB points: 
USB: 401 - 2102 Hz (1701 Hz) 


VV VV VV VV VV MV 


VVVNVVV VV WV 


VVVV VV VV WV 


VV VV V 


LSB: 431 - 2148 Hz (1717 Hz) 


So as you can see rather narrow. The radio has passband tuning and a 
position for fitting a second smaller filter. Usually a 500 Hz filter is 
fitted in the two IFs (9 MHz and 455 MHz). 


On the other hand most of the military radios have an IF/audio bandwidth 
of 300 - 3000 Hz at the -3db points, with a group delay variation of 
+-0.5 ms between 800 - 2800 Hz. I think no HAM tranceiver can match this. 


The Harris transceivers used by the U.S. DoD (AN/URC-119) do 
indeed have a 300 - 3000 Hz, 3db bandpass as well as others 
used by DoD agencies. This is one reason the TACTERM and 
other MIL-STD-188-110A modems work so well with these systems. 


IMHO, we (hams) will have to decide if we want to "build" a 
modem to fit into a 500 -2100 Hz -6db bandpass or replace the 
filters in our HF rigs for ones that will be 300 - 3000 Hz. 


Admittedly those of us interested in high speed HF data 
transmission will initially be a very small minority. However, 
I believe once we can show that robust 2400 BPS data can be 
sent on HF, there will be many clamoring to get this "new 
ham technology. At this point, manufacturers may begin 
offering an optional wide SSB filter. 


I would recommend that you (I didn't say we because I'm not 
doing the "“work") begin with a modulation scheme that will 
fit into a 500 - 2100 Hz bandpass with the ability to expand 
to a scheme that can use a 300 - 3000 Hz bandpass. 


Pawel is always asking difficult questions, :-) 

It is clear there is an optimum rate at a given moment and for given 
propagation conditions, the only problem is that the propagation varies 

all the time. I have seen a study made by the Swedish Defence 

establishment that tested FSK modulation rates between 37 Baud and 600 Baud. 
They found that you even could run happily at 600 Bauds from time to 

time, specially during day time on a good day time frequency. One thing 

to keep in mind when reading such studies is that the military usually 

work with links between 100 - 1000 km, so there is no real DX involved, :-) 


The above is mostly true...actually 40/45 - 1200/1500 km and 
they try to punch thru as much data as possible in the 
shortest time. Thus, they will use 300 (even 600) baud AFKS 
when conditions would hardly support 150 baud. 


>From what I have read so far I think 75 Baud is a very conservative rate 
which undoubtedly will work under almost all conditions. Personally I 
think the optimal, safe rate is closer to 125 Baud. As far as I have 
understood it should also be safer to run 125 Baud DQPSK than 125 Baud 
FSK, but this might again depend on the design of the FSK demodulator. 


HAL, in their CLOVER II papers, suggest that 150 baud is the 


maximum baud rate to consider using on HF. This is also 
suggested by Harris Corp, Rockwell Collins and Magnavox. 
They may all be using data from research done by Stanford 
Research Institute. Many "old-timers" say the reason RTTY 
and ASCII were never used above 100/110 baud, respectively, 
is that at the end of WWII it was determined that these were 
the maximum baud rates that HF would support. 


> I have seen a reference to one modem using 66 tones with 37.5 Baud. I 
> can't quite remember what waveform it used, but I think it was DPSK. 
> Personal ly I think I 
would use less tones and a higher symbol rate. > 

> 73's Frode 


> 

> 

> Frode Weierud Phone : 41 22 7674794 

> CERN, SL Fax : 41 22 7679185 

> CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 
> 


73, Walt@home.2.nite 


Kelly AFB, TX and McClelland AFB, CA were xnotx saved. Another great U.S. 
military mistake. We should have learned from General Custer's mistake. 


This is my personal opinion and does in no way represent the view of the 
DoD, USAF or any other official U.S. Government Agency. 


Walter D. DuBose 


From forrerj@ucs.orst.edu Thu Jul 13 18:41:46 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id SAA19988 for 
<hfsig@tapr.org>; Thu, 13 Jul 1995 18:41:31 -0500 
Received: from p08.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AAQ4815; Thu, 13 Jul 1995 16:41:20 -0700 
Message-Id: <9507132341.AA04815@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 13 Jul 1995 15:53:30 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:461] Hilbert 


Charles, 


Good question. 


>Here is a question for the group, 

> 

> If one implements a Hilbert Transform using a FIR filter and the 
>Parks Mc Clelland algorithm which sample in the input buffer is the 
>one that is 90 deg phase different? is it the one in the middle? 

> 


Lets see - think of it this way. Consider the Hilbert transform as a black 
box where you feed your real-valued time series in. The Hilbert transformer 
takes one input and has two outputs, the two outputs are identical except 
that they are 90 degrees out of phase, i.e. like sine is the same as a 
cosine 90 degrees phase shifted. The output of the Hilbert transformer is 
now an analytical signal where one branch could be thought of as the "real" 
and the other the "imaginary". This arrangement has some "magical" 
properties when it comes to modulation/demodulation but I'll leave that for 
the moment. To return to the question: EVERY point of the input buffer is 
affected by the transformation. Its kind of similar as doing an FFT and 
taking a frequency bin and asking "which data point from the time series 
made this bin's content?" The answer is "each and every data point". 


Some other useful tips about the Hilbert transform. 


1) Be aware of Parks-McClellan FIR code laying around the Internet. Many 
version does not compute a valid Hilbert transform - the way you know is to 
inspect the coefficients, they should alternate with every other one being 
equal zero. 


2) If you use a single FIR Hilbert transform for your "Q" branch, make sure 
that the other branch i.e. your "I" is delayed by the "same" group delay, 
i.e. if your Hilbert transform has 39 taps, you need a delay of 39/2 = 19.5 
(use either 19 or 20) taps delay for your "I". 


3) One may also do the same thing using regular "comb" FIR filters (every 
other coefficient being zero). Then derive two versions from this set of 
coefficients, one multiplied by cosine, the other by sine. Now you will have 
90 degree difference in the paths, but also have the correct group delay in 
each path. 


4) If you use the P-McC algorithm for designing the transform, you will find 
that it is impossible to attain infinitely narrow transition zones. These 
will result in "holes" in the transform - particularly at the origin and 
band edge. Most often you may just ignore these effects, but be aware that 
you need high enough order filter (look at the number of dB rejection you 
get - anything better than say 30-40 dB is usable). 


Above is more or less correct - feel free to jump in and correct me 
otherwise. I'm also just learning about the finer points. 


73's 


--Johan 


From bm@lynx.ve3jf.ampr.org Thu Jul 13 21:25:08 1995 
Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id VAA21143 for 
<hfsig@tapr.org>; Thu, 13 Jul 1995 21:25:01 -0500 
Received: by lynx.ve3jf.ampr.org (Linux Smail3.1.28.1 #14) 
id mOsWaQy-0002qeC; Fri, 14 Jul 95 02:24 GMT 
Message-Id: <mOsWaQy-0002qeC@lynx.ve3jf£.ampr.org> 
From: bm@lynx.ve3j£.ampr.org (Barry McLarnon VE3JF) 
Subject: Re: [HFSIG:455] Re: ANDVT TACTERM Documentation 
To: hfsig@tapr.org 
Date: Fri, 14 Jul 1995 02:24:56 +0000 (GMT) 
In-Reply-To: <F2734C1ACO22A758@chopin.ifj.edu.pl> from "JALOCHA@chopin.ifj.edu.pl" 
at Jul 12, 95 08:23:13 am 
X-Mailer: ELM [version 2.4 PL23] 
Content-Type: text 
Content-Length: 1932 


Pawel asks: 

> By the way is there an optimal symbol rate for HF and DQPSK ? 
> If too high, the multi-paths come into effect, 

> if too low, the phase incoherency affects the data... 

> so where is the optimum ? 


This is an age-old question. :-) I have a copy of a paper from 1962 
(8th Nat'l Communications Symposium) by one Heinz Fiege-Kollmann, 
entitled "The optimum bit length for HF data transmission", in which he 
concludes that the optimum symbol length for DPSK lies somewhere between 
5 ms and 15 ms. He says that the optimum is a broad one, but that 
performance degrades more quickly as the symbol length is shortened 

than when it is increased. This was based on work done during the 
devlopment of the granddaddy of all parallel-tone modems, the Collins 
Kineplex, in the mid- to late-50's. The oldtimers usually used 75 or 
100 baud, and they probably knew what they were doing... :-) 


Just think of all those racks of equipment that can now be replaced by 
one DSP chip... 


One common technique in parallel-tone modems that I don't recall seeing 
mentioned here (but I probably missed it) is the use of a guard interval 
during the first part of the symbol interval. Energy received during 

the guard interval, which hopefully includes most of the multipath, is 
excluded from the decision process. One set of parameters that comes to 
mind (probably from Kineplex) is an overall symbol length of 13.33 ms 

and a useful symbol length of 9.09 ms, giving 4.24 ms of guard time and 
an orthogonal tone spacing of 110 Hz. Guard intervals are also used for 
multipath mitigation in the more recent high-speed VHF/UHF OFDM systems, 
such as the Eureka 147 DAB system. For example, Eureka Mode 1 has a 0.25 


ms guard interval, 1 ms useful symbol length, and 1536 tones(!) with 1 
kHz spacing. 


Barry 


Barry McLarnon VE3IJF/VA3TCP 
Ottawa Amateur Radio Club Packet Working Group 
Email: bm@hydra.carleton.ca or bm@lynx.ve3jf£.ampr.org 
From forrerj@ucs.orst.edu Fri Jul 14 01:01:34 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id BAA24247 for 
<hfsig@tapr.org>; Fri, 14 Jul 1995 01:01:30 -0500 
Received: from p02.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 
id AA12819; Thu, 13 Jul 1995 23:01:24 -0700 
Message-Id: <9507140601.AA12819@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 13 Jul 1995 22:13:33 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:464] Re: ANDVT TACTERM Documentation 


Hi Barry, 


<<---some lines deleted--->> 


>One common technique in parallel-tone modems that I don't recall seeing 
>mentioned here (but I probably missed it) is the use of a guard interval 
>during the first part of the symbol interval. Energy received during 
>the guard interval, which hopefully includes most of the multipath, is 
>excluded from the decision process. One set of parameters that comes to 
>mind (probably from Kineplex) is an overall symbol length of 13.33 ms 
>and a useful symbol length of 9.09 ms, giving 4.24 ms of guard time and 
>an orthogonal tone spacing of 110 Hz. Guard intervals are also used for 
>multipath mitigation in the more recent high-speed VHF/UHF OFDM systems, 
>such as the Eureka 147 DAB system. For example, Eureka Mode 1 has a 0.25 
>ms guard interval, 1 ms useful symbol length, and 1536 tones(!) with 1 
>kHz spacing. 


Yes, quite right - thanks for reminding us about this issue: 


In addition to the multipath performance, there is yet another reason for 
the guard bands: 


In J.D. Ralphs' book: Principles and Practise of Multi-frequency Telegraphy, 
page 41, the theory of the guard time is discussed. The gist of the idea is 
that most of the spectral spill-over into adjacent bins occurs at bit 


transitions and are mostly noticible right right at or near those time 
instances. If a "dead" zone or guard interval is used (i.e. the 
integrator/FFT excuding that part of the signal), he shows a significant 
improvement in demodulator S/N is possible due to using the guard band. 


This same book (page 113) looks at the 16 DPSK parallel-tone modem and 
mentions a guard band of 4 ms out of the 13.3ms (75 baud) used for those 
modems. There are some further examples of this topic - I'm too lazy to look 
for them at the moment. 


--Johan Forrer, KC7WW 


From chbrain@dircon.co.uk Fri Jul 14 01:53:44 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id BAA24731 for 

<hfsig@tapr.org>; Fri, 14 Jul 1995 01:53:39 -0500 

Received: by felix.dircon.co.uk id AA17004 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Fri, 14 Jul 1995 07:53:33 +0100 

Message-Id: <199507140653.AA17004@felix.dircon.co.uk> 

Received: from ad030.pool.dircon.co.uk(193.128.231.30) by amnesiac via smap (V1.3) 
id sma016996; Fri Jul 14 07:53:08 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 14 Jul 1995 06:03:17 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:463] Re: Hilbert 


>2) If you use a single FIR Hilbert transform for your "Q" branch, make sure 
>that the other branch i.e. your "I" is delayed by the "same" group delay, 
>i.e. if your Hilbert transform has 39 taps, you need a delay of 39/2 = 19.5 
>(use either 19 or 20) taps delay for your "I". 


> 

>73's 

> 
>--Johan 
> 


Thanks Johan, 

The above is what I wanted to know! 

I am using a program called PC-DSP written by Oktay Alkin, I have used it to 
design FIR filters. It is the program that Jon Bloom KE3Z described in QEX a 
year ago (it cmes with a book and costs $29). 

Amoungst other things it allows you to design a Hilbert transfor either 
using Parks 
Mc Clelland or Fourier. 


I was thinkinking of incorporating it into my 8 ary modem on the C50. However 
it seems to have enough processing power to work with a larger complex 
transform. I guess I could use Goertzel (???) algorithm instead! 


Regards Charles 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From frode@dxcern.cern.ch Fri Jul 14 03:44:55 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id DAA25544 for 
<hfsig@tapr.org>; Fri, 14 Jul 1995 03:44:45 -@500 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AAQ1830; Fri, 14 Jul 1995 10:44:25 +0200 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA23739; Fri, 14 Jul 1995 10:44:24 +0200 
Date: Fri, 14 Jul 1995 10:44:22 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:462] Re: ANDVT TACTERM Documentation 
In-Reply-To: <mOsWXWh-OQ002FEC@sacdm10.kelly.af.mil> 
Message-Id: <Pine.ULT.3.91.950714094315 .20933A-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Thu, 13 Jul 1995, WALT DUBOSE - K5YFW wrote: 


IMHO, we (hams) will have to decide if we want to "build" a 
modem to fit into a 500 -2100 Hz -6db bandpass or replace the 
filters in our HF rigs for ones that will be 300 - 3000 Hz. 


Admittedly those of us interested in high speed HF data 
transmission will initially be a very small minority. However, 
I believe once we can show that robust 2400 BPS data can be 
sent on HF, there will be many clamoring to get this "new 
ham technology. At this point, manufacturers may begin 
offering an optional wide SSB filter. 


I would recommend that you (I didn't say we because I'm not 
doing the "“work") begin with a modulation scheme that will 
fit into a 500 - 2100 Hz bandpass with the ability to expand 
to a scheme that can use a 300 - 3000 Hz bandpass. 


VV VV VV VV VV VV VV VV 


I agree with you that this is the most promising approach. We should 
reduce the number of tones to be able to nicely fit within the available 
bandwidth of standard ham tranceivers. We should make the modem such that 
it would be easy to reconfigure it to work with different number of 
tones. However to have something which is generally useable, it would 


mean that we will have to have a way of distinguishing between a 
transmissions using the full tone set and ones using a reduced tone set. 
Perhaps this could be done by using a different number of Doppler tones. 


It is rather clear from recent papers that there is trend away from 

the parallel tone modems and towards the single tone modems. I read 
recently a comparison between these types of modems and it was indicated 
that you would need 15 dB more power with a parallel modem than with the 
serial tone modem to achieve an error rate of 1E-3. During this 
comparison both modems were running without ECC. I nevertheless think we 
are doing the right thing in going for the parallel tone modems for the 
time being as the serial tone modems need rather complex channel 
equalizers and channel quality analysis algorithms. Serial tone modems 
should come when we have got thorough experience with the parallel tone 
ones. 


The ANDVT TACTERM modem is using an EOM (End-Of-Message) sequence that 

was meant to insure a rapid changeover between receive/transmit. Initially 
I though this would have little use for amateur use, but I am now 
wondering if it would be useful after all. It would insure that at the 

end of transmission the receiving station would quickly be able to take 
the link, or to fall back into preamble tracking mode. If not used it is 
possible that an error burst could confuse the receiver and that it would 
stay in data receive mode, while the transmitting station is sending a 

new Doppler/Sync sequence. 


Would this be of any use? Anyone with an opinion? 


73's Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From JALOCHA@chopin.ifj.edu.pl Fri Jul 14 06:59:30 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id GAA27081 for 
<hfsig@tapr.org>; Fri, 14 Jul 1995 06:59:23 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id NAA17533 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Fri, 14 Jul 1995 13:58:43 +0200 

Date: Fri, 14 Jul 1995 13:58 GMT+1 

Subject: Re: [HFSIG:467] Re: ANDVT TACTERM Documentation 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <7A637F4DE022C218@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


> IMHO, we (hams) will have to decide if we want to "build" a 
> modem to fit into a 500 -2100 Hz -6db bandpass or replace the 
> filters in our HF rigs for ones that will be 300 - 3000 Hz. 


My two cents: 


cent #1: 

I want to stress that for the multi-tone modem the passband uniformity 

is not very much critical. It should accept ripples up to 12-18 dB 

(the Tx filter is in must more critical). This is because every tone 
occupies small bandwidth and it is being decoded independently. 

That if carrier #1 has an amplitude of 10 but carrier #8 only 1 

it really doesn't matter that much. 

What I see for the FT757GXII is that the SSB filter passes 300-3000 Hz 
within maybe 6dB - this you can see with your S-meter while tuning across 
a dead carrier (turn on the internal calibrator). Then the post-demodulation 
audio filters do the "nasty" job of attenuation the higher frequencies 

so on the output the last carrier is 3 times weaker than the "top" one. 
But here I don't really care... the noise gets 3 times weaker too, 

so the demodulator will experience as many errors as for any other 
carrier. 


cent #2: 

When I was younger :-) I read many book on building SSB tranceivers 

and all the SSB filters mentioned there were 2.7 kHz wide - looked to me 
like a very standard bandwidth. 


Admittedly those of us interested in high speed HF data 
transmission will initially be a very small minority. However, 
I believe once we can show that robust 2400 BPS data can be 
sent on HF, there will be many clamoring to get this "new 
ham technology. At this point, manufacturers may begin 
offering an optional wide SSB filter. 


VV VV VV 


They should just offer a standard 2.7 kHz filter - no need for "wide" :-) 
What might be nice however, is the capability to bypass all the pre-modulation 
and post-demodulation audio circuits. 


>It is rather clear from recent papers that there is trend away from 
>the parallel tone modems and towards the single tone modems. 


We should learn the "single tone modem" principles: does it use some sort 
of equalizer to remove the effect of multipaths ? 


>I read 

>recently a comparison between these types of modems and it was indicated 
>that you would need 15 dB more power with a parallel modem than with the 
>serial tone modem to achieve an error rate of 1E-3. 


And what is the reason for such a difference ? 

This effect may come from the fact that for a multi-tone modem 

you need to transmit with lower average power because the envelope 

of the signal is not constant. So was the "power" the tranceiver power 
or was this the signal's power on the air ? 


>The ANDVT TACTERM modem is using an EOM (End-Of-Message) sequence that 
>was meant to insure a rapid changeover between receive/transmit. Initially 


>I though this would have little use for amateur use, but I am now 
>wondering if it would be useful after all. 


As for now I am going to use EOM sequence but different that the one for 
TACTERM. I will transmit random data with the maximum phase error 

(45 degrees) with the intention to generate maximum receiver decoder 
errors. I hope this will speed up the DCD swith off. If a noise burst 
comes right at the EOM, it will only slow down the DCD switch off by 

a factor of two. 


My code for the DSPCARD4 acquires proper symbol sync. now, and switches 
to the data decoding phase. It even decodes the data I only didn't check 
yet if the data come out right. 


Pawel 
From frode@dxcern.cern.ch Fri Jul 14 10:09:35 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id KAA29274 for 
<hfsig@tapr.org>; Fri, 14 Jul 1995 10:09:29 -0500 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AA24631; Fri, 14 Jul 1995 17:09:27 +0200 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA11188; Fri, 14 Jul 1995 17:09:25 +0200 
Date: Fri, 14 Jul 1995 17:09:23 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:468] Re: ANDVT TACTERM Documentation 
In-Reply-To: <7A637F4DE022C218@chopin.ifj.edu.pl> 
Message-Id: <Pine.ULT.3.91.950714162737 .7711A-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Fri, 14 Jul 1995 JALOCHA@chopin.ifj.edu.pl wrote: 


cent #2: 

When I was younger :-) I read many book on building SSB tranceivers 

and all the SSB filters mentioned there were 2.7 kHz wide - looked to me 
like a very standard bandwidth. 


VV VV Vv 


You are right that was the standard, but with the band conditions getting 
worse there has been a recent trend to make filters with 1.8 to 2.1 kHz 
bandwidth. I think the 1.8 kHz filters are really for the contest 
operators, but more and more rigs appear with the narrow type of SSB 
filter at 2.1 kHz as the standard filter. Pawel, you are getting old ;-) 


They should just offer a standard 2.7 kHz filter - no need for "wide" :-) 
What might be nice however, is the capability to bypass all the pre-modulation 
and post-demodulation audio circuits. 


VV VV 


I think this is not a bad idea. It should be possible to switch out the 
audio shaping when running the type of digital modes we are talking about. 


> 
> We should learn the "single tone modem" principles: does it use some sort 
> of equalizer to remove the effect of multipaths ? 


Yes, they are using equalizers, but not simple static equalizers. The 
equalizers are adaptive to be able to cope with the randomly changing HF 
channel. They therefore are using RTCE (Real Time Channel Estimation) to 
evaluate the channel and drive the adaptive equalizer. This can be rather 
complex. Some serial tone modems are using special training sequences 
after the preamble which is then analyzed and evaluted by the receiving 
modem. These modems today run around 3000 bps in a 1800 Hz bandwidth, 
QDPSK modulating a single carrier usually at 1800 Hz. The Ecotel modem 
from Telefunken I think is using 1650 Hz as the carrier frequency. 


>I read 

>recently a comparison between these types of modems and it was indicated 
>that you would need 15 dB more power with a parallel modem than with the 
>serial tone modem to achieve an error rate of 1E-3. 


And what is the reason for such a difference ? 

This effect may come from the fact that for a multi-tone modem 

you need to transmit with lower average power because the envelope 

of the signal is not constant. So was the "power" the tranceiver power 
or was this the signal's power on the air ? 


VV VV VV VV VV VV 


This I got from their published S/N ratio versus BER (bit-error rate) 
diagram that showed about 15dB lower S/N figure for the serial tone modem 
for a BER of 1E-3. So I sort of extrapolated that to mean that I would 
need a 15dB stronger signal from the parallel tone modem to get the same 
BER figure, or did I interpret that wrong? 


As for now I am going to use EOM sequence but different that the one for 
TACTERM. I will transmit random data with the maximum phase error 

(45 degrees) with the intention to generate maximum receiver decoder 
errors. I hope this will speed up the DCD swith off. If a noise burst 
comes right at the EOM, it will only slow down the DCD switch off by 

a factor of two. 


VV VV VV MV 


That agrees with my idea as well. You method is perhaps a lot easier than 
to try to correlate a PN sequence to detect the EOM. If it does the same 
job correctly why not. 


My code for the DSPCARD4 acquires proper symbol sync. now, and switches 
to the data decoding phase. It even decodes the data I only didn't check 
yet if the data come out right. 


VV VV Vv 


I have even heard some rumours that your waveform already have made it on 


the air via HF. I hope we will get some more reports on these trials. 


73's Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From forrerj@ucs.orst.edu Fri Jul 14 12:24:49 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id MAA31368 for 
<hfsig@tapr.org>; Fri, 14 Jul 1995 12:24:29 -@500 
Received: from p09.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AA15631; Fri, 14 Jul 1995 10:24:14 -0700 
Message-Id: <9507141724.AA15631@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 14 Jul 1995 09:36:27 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:466] Re: Hilbert 


Charles, 


> I am using a program called PC-DSP written by Oktay Alkin, I have used it to 
>design FIR filters. It is the program that Jon Bloom KE3Z described in QEX a 
>year ago (it cmes with a book and costs $29). 

> Amoungst other things it allows you to design a Hilbert transfor either 
>using Parks 

>Mc Clelland or Fourier. 


Sounds like you have it all under control. 


>I was thinkinking of incorporating it into my 8 ary modem on the C50. However 
>it seems to have enough processing power to work with a larger complex 
>transform. I guess I could use Goertzel (???) algorithm instead! 

> 


If I may add my two cents' worth: 


Interesting that you should bring this up. Goertzel's method is nice if you 
only need a few FFT bins and probably will be OK for what you need. However, 
think about this for a minute: When you compare the spectral energy ina 
particular bin as measured with an FFT vs. what you get when you use a nice 
sharp FIR filter, you will find that the dynamic range, i.e. the magnitude 


of your bigest - smallest number, is much smaller for the FFT case, than for 
the FIR output. It is not difficult to see why this is the case when one 
consider that a frequency bin is made up of many summed brances, all 
containing multiplies. A FIR filter, on the other hand, has a very 
predictable outcome as far as saturation and dynamic range is concerened, 
especially if coefficients have been engineered to sum to "unity" response 
in the worst case senario. Why folks don't use them, is because you need to 
many taps to make a decent filter bank - DSP's usually run out of clock 
ticks. (There are tricks to lower the filter order, but at a cost of much 
higher sampling rates. I'll leave it at that for the moment.) 


That being the case, and things getting even worse for an integer FFT, you 
may want to consider doing the floating point Goertzel. I have seen the 
floating point Goertzel in some books. I believe that the ‘C50 has some 
special instructions that helps out doing floating point? This should 
already help a lot for weak signals. 


Good luck with your project. 
--Johan, KC7WW 


From forrerj@ucs.orst.edu Fri Jul 14 12:25:32 1995 
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id MAA31376 for 
<hfsig@tapr.org>; Fri, 14 Jul 1995 12:24:43 -@500 
Received: from p09.tO.monrotel.com by ucs.orst.edu; 
(5.65v3.0/1.1.8.2/24Sep94-1201PM) 

id AA15857; Fri, 14 Jul 1995 10:24:25 -0700 
Message-Id: <9507141724.AA15857@ucs.orst.edu> 
X-Sender: forrerj@ucs.orst.edu 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 14 Jul 1995 09:36:37 -0800 
To: hfsig@tapr.org 
From: forrerj@ucs.orst.edu (Johan Forrer) 
Subject: Re: [HFSIG:467] Re: ANDVT TACTERM Documentation 


>On Thu, 13 Jul 1995, WALT DUBOSE - K5YFW wrote: 


> 

>> 

>> IMHO, we (hams) will have to decide if we want to "build" a 
>> modem to fit into a 500 -2100 Hz -6db bandpass or replace the 
>> filters in our HF rigs for ones that will be 300 - 3000 Hz. 

>> 

>> Admittedly those of us interested in high speed HF data 

>> transmission will initially be a very small minority. However, 
>> I believe once we can show that robust 2400 BPS data can be 
>> sent on HF, there will be many clamoring to get this "new" 


>> ham technology. At this point, manufacturers may begin 


>> offering an optional wide SSB filter. 


>> 
>> I would recommend that you (I didn't say we because I'm not 
>> doing the "work") begin with a modulation scheme that will 
>> fit into a 500 - 2100 Hz bandpass with the ability to expand 
>> to a scheme that can use a 300 - 3000 Hz bandpass. 

> 


In a document that I received from Phil Karn, it describes in a fair amount 
of detail, how one outfit did their own 16-tone MIL-STD-188 modem. They also 
had to deal with this same problem of using readily-available SSB rigs. 
Their solution was to use an audio band 935 - 2585 Hz for the tones. 


>I agree with you that this is the most promising approach. We should 
>reduce the number of tones to be able to nicely fit within the available 
>bandwidth of standard ham tranceivers. We should make the modem such that 
>it would be easy to reconfigure it to work with different number of 
>tones. However to have something which is generally useable, it would 
>mean that we will have to have a way of distinguishing between a 
>transmissions using the full tone set and ones using a reduced tone set. 
>Perhaps this could be done by using a different number of Doppler tones. 
> 

>It is rather clear from recent papers that there is trend away from 

>the parallel tone modems and towards the single tone modems. I read 
>recently a comparison between these types of modems and it was indicated 
>that you would need 15 dB more power with a parallel modem than with the 
>serial tone modem to achieve an error rate of 1E-3. During this 
>comparison both modems were running without ECC. I nevertheless think we 
>are doing the right thing in going for the parallel tone modems for the 
>time being as the serial tone modems need rather complex channel 
>equalizers and channel quality analysis algorithms. Serial tone modems 
>should come when we have got thorough experience with the parallel tone 
>ones. 


I also believe that there is no question that a single tone system at low 
baud rate will outperform a parallel tone system (in terms of BER for any 
given s/n). However, in the end it becomes a tradeoff between speed and 
robustness. The parallel modem will certainly have the advantage for speed. 
I think one have to be careful when reading papers about these things 
without normalizing everything to the same units (BER for given S/N at 
bits/second/hertz). This is confusing. 


> 

>The ANDVT TACTERM modem is using an EOM (End-Of-Message) sequence that 
>was meant to insure a rapid changeover between receive/transmit. Initially 
>I though this would have little use for amateur use, but I am now 
>wondering if it would be useful after all. It would insure that at the 
>end of transmission the receiving station would quickly be able to take 
>the link, or to fall back into preamble tracking mode. If not used it is 
>possible that an error burst could confuse the receiver and that it would 
>stay in data receive mode, while the transmitting station is sending a 


In an FEC situation, especially where variable length messages are sent, 
every little bit of framing/blocking information is helpful to the remote 
decoder. In AMTOR FEC, for example, there is such a "go back to standby" 
sequence sent at the end of the transmission. It is repeated several times 
and only one of those is needed to get the remote to act on. If the remote 
missed it due to interference, then a rapid succession of errors tells that 
it has lost sync, whereupon it goes back to hunt for sync. 


If the sync pre-amble is designed cleverly, it may be possible to write an 
algorithm that is hunting for it all the time - a daemon. When it sees it, 
it forces a frame reset. As an interesting aside, in Pactor, the designers 
choose such a poor sync header, that this is not possible - the remote 
decoder have to find frames by brute force search for a valid CRC, i.e. a 
whole frame buffer of samples have to searched at every new data sample - 
then once the CRC is valid, can one inspect the sync symbol. This is one 
reason why the early Pactor units could not do automatic signal detection of 
all modes - there Z80 processor was out of cycles. 


--Johan 


From gjones@tenet.edu Fri Jul 14 13:40:55 1995 

Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) 

by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id NAA32272; Fri, 14 Jul 

1995 13:40:26 -0500 

Received: (from gjones@localhost) by Leslie-Francis.tenet.edu (8.6.12/8.6.12) id 

NAA28968; Fri, 14 Jul 1995 13:40:11 -0500 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199507141840.NAA28968@Leslie-Francis.tenet.edu> 

Subject: DCC Paper Deadline! 

To: tapr-bb@tapr.org (TAPR-BB mailing), netsig@tapr.org (NETSIG mailing), 
bbssig@tapr.org (BBS SIG mailing), hfsig@tapr.org (HF SIG mailing), 
dsp-93@tapr.org (DSP-93 Build), aprssig@tapr.org (BBS SIG mailing), 
amsat-bb@amsat.org (AMSAT BB Mail Group) 

Date: Fri, 14 Jul 1995 13:40:11 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1780 


Don't forget -- Friday, July 21st! Deadline for ARRL DCC Article Submissions 


x Anyone interested in digital communications is invited to submit a paper for 
publication in the Conference Proceedings. Articles are welcome on any 
aspect of digital communications. 


x Presentation at the Conference is not required for publication. 
x Papers are due by July 21, 1995, and should be submitted to 


Maty Weinberg, ARRL, 225 Main Street, Newington, CT 06111 or via the 
Internet to mweinberg@arrl.org 


x Please contact Maty for detailed format requirements. 


* It is not to late to start writing! 


If you think you will be late in submitting your paper(s), contact Maty to 
arrange details. 


14th Annual ARRL Digital Communications Conference 
September 8-10th, 1995 
Arlington, Texas (minutes from DFW airport) 


The ARRL Digital Communications Conference is an international forum for 
radio amateurs in digital communications, networking, and related 
technologies to meet, publish their work, and present new ideas and 
techniques for discussion. Presenters and attendees will have the 
opportunity to exchange ideas and learn about recent hardware and 
software advances, theories, experimental results, and practical 
applications. The Digital Communications Conference is not just for 

the digital elite, but for digitally-orientated amateurs of all 

levels of experience. 


For further information: 


E-Mail: TAPR@TAPR.ORG 
Web : http://www.tapr.org/tapr 
ftp : £tp://ftp.tapr.org/tapr/95_DCC_Flyer. pdf 


Tucson Amateur Packet Radio 
8987-309 E Tanque Verde Rd #337 * Tucson, Az * 85749-9399 x 817-383-0000 


From k5yfw@sacdm10.kelly.af.mil Fri Jul 14 15:05:01 1995 
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id PAAOQO705 for 
<hfsig@tapr.org>; Fri, 14 Jul 1995 15:04:48 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsWqcq-0001v2C; Fri, 14 Jul 95 14:42 CDT 
Message-Id: <mOsWqcq-0001v2C@sacdm10.kelly.af.mil> 
Date: Fri, 14 Jul 95 14:42:15 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:469] Re: ANDVT TACTERM Documentation 
To: hfsig@tapr.org 
X-orig-date: Fri, 14 Jul 1995 10:14:26 -0500 
X-orig-from: Frode Weierud <frode@dxcern.cern.ch> 
X-orig-message-ID: <Pine.ULT.3.91.950714162737 .7711A-100000@dxcern.cern.ch> 


The Thread sez: 
> > They should just offer a standard 2.7 kHz filter - no need for "wide" :-) 


> What might be nice however, is the capability to bypass all the pre-modulation 
> and post-demodulation audio circuits. 


I think this is not a bad idea. It should be possible to switch out the 
audio shaping when running the type of digital modes we are talking about. 


VV VVV WV 


This is a reality check: 


Getting a manufacturer to "custom" build an HF rig to fit the 
needs of a small groups of users (like us) is unlikely...Why? 
Because I dare say that few HF rig manufacturers build more 
than 50,000 of any certain model (at an average of $600US, 
that's $30,000,000 in wholesale sales). 


It is more than likely that they are building HF rigs with the 
filters they have to support the large DX community where a 
narrow bandpass is desirable. 


I believe you must design a modem that can be used with the HF 
rigs on the market (today) and prove the modems worth before 
you will find manufactures building and selling HF rigs with 
the filtering/audio response you/we desire 


> I have even heard some rumors that your waveform already have made it on 
> the air via HF. I hope we will get some more reports on these trials. 
> 


If you mean 39 or 16 parallel tone modems (such as in the 
TACTERM), there are many U.S. DoD agencies and some 
commercial HF users carrying on HF data communications using 
these modem protocols. I have heard what sounds like strong 
noise peaks on HF and suspect that many of these are the 
multi-tone and serial tone modems at work. 


73, Walt 
From willi_r@mail.uwlax.edu Fri Jul 14 19:03:03 1995 
Received: from mail.uwlax.edu (mail.uwlax.edu [138.49.128.137]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id TAA04178 for 
<hfsig@tapr.org>; Fri, 14 Jul 1995 19:02:57 -0500 
From: willi_r@mail.uwlax.edu 
Received: from dial03.wwrdc.uwlax.edu by mail.uwlax.edu; 
id AA10355; NX5.67d/42; Fri, 14 Jul 95 19:01:55 -0500 
Date: Fri, 14 Jul 95 19:01:55 -0500 
Message-Id: <9507150001.AA10355@mail.uwlax.edu> 
X-Sender: willi_r@mail.uwlax.edu 
X-Mailer: Windows Eudora Version 1.4.3 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 
Subject: CLOVER II vs. Pactor II 


There were two things holding me back from making a decision to "invest" in 
new hf modem hardware. 1) Legal operation of automatic and semi-automatic 
operation in the U.S. and 2) Which is the best hf£ mode for hi speed transfer 
under all condx whether for highest speed or best thruput under 
deteriorating condx. 


Well #41 is now settled and legal here in U.S.A. 
But #2 is still up in the air. 


Anybody have any preliminary information on what the comparison will be? OK, 
how about any opinions? Pactor II sounds better than CLOVER II in that it 
may have faster thruput and better weak signal abilities, but we need some 
tests. Surely, some of you folks who are the worlds top leaders in hf issues 
are either doing some tests yourself or know of others. This would be 
bugging me to no end if I had the equipment. I would have to know.:-) 


The alternative is for one of the digital ham companies to come out with a 
unit that will do both modes or better yet, do one now and have a guaranteed 
upgrade path for a reasonable price (like no more than 100 bux) to the other 
mode within a year or so. 

I have no idea of the approximate cost there is to license these modes, but 
if there was a DSP modem that had the horsepower and the support of the 3rd 
party software authors to make it work with Winlink and similar 
connectivity, I know I would be a buyer at the 500-700 bracket. 


I did ask HAL about this but they said (in a very nice way) that they could 
not commit to this concept. Maybe licensing is really high priced but find 
it hard to believe it could be over 20-30 bux per license. Am I living in 
fantasyland? 


Wonder if the TAPR DSP-93 board could handle these new modes? Wonder if it 
could get the support like the HAL boards do? I sure would not have a 

problem with paying a modest price for embedded call software for TAPR 

software (50 bux or so) similar to what the IDRA (International Digital 

Radio Association) formerly the ADRS does with their rather successful software. 


Rick, KV9U 


From frode@dxcern.cern.ch Sat Jul 15 10:41:13 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id KAA10367 for 
<hfsig@tapr.org>; Sat, 15 Jul 1995 10:41:09 -0500 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AAQ0Q465; Sat, 15 Jul 1995 17:41:07 +0200 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA22276; Sat, 15 Jul 1995 17:41:02 +0200 
Date: Sat, 15 Jul 1995 17:41:02 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:473] Re: ANDVT TACTERM Documentation 
In-Reply-To: <mOsWqcq-0001v2C@sacdm10.kelly.af.mil> 


Message-Id: <Pine.ULT.3.91.950715173400 .22055B-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Fri, 14 Jul 1995, WALT DUBOSE - K5YFW wrote: 


I believe you must design a modem that can be used with the HF 
rigs on the market (today) and prove the modems worth before 
you will find manufactures building and selling HF rigs with 
the filtering/audio response you/we desire 


VV VV WV 


I agree we will probably not get the rig manufacturers to tailor their 

rigs to our needs. What I had in mind was simply a data input/output like 
you now find on the new VHF/UHF rigs for packet radio. This data I/0 will 
simply bypass the audio shaping that you have in most rig. It will not 
solve the problem with lousy filters, but it should improve things slightly. 


> > I have even heard some rumors that your waveform already have made it on 
> > the air via HF. I hope we will get some more reports on these trials. 
>> 


If you mean 39 or 16 parallel tone modems (such as in the 
TACTERM), there are many U.S. DoD agencies and some 
commercial HF users carrying on HF data communications using 
these modem protocols. I have heard what sounds like strong 
noise peaks on HF and suspect that many of these are the 
multi-tone and serial tone modems at work. 


VV VV VV VV 


Yes, I have heard several of these transmissions. They are on every day. 
What I really meant with my remark is that Pawel's multitone modem has 
made it on HF. A few hams are now actively testing his modem on VHF and 
HF. Just to let you see that things are moving extremely fast ahead. 


73's Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From k5yfw@sacdm10.kelly.af.mil Sun Jul 16 18:56:57 1995 
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id SAA17449 for 
<hfsig@tapr.org>; Sun, 16 Jul 1995 18:56:53 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsXdTi-00016QC; Sun, 16 Jul 95 18:52 CDT 
Message-Id: <mOsxXdTi-00016QC@sacdm10.kelly.af.mil> 
Date: Sun, 16 Jul 95 18:52:05 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Parallel vs Serial Tone Modems 
To: hfsig@tapr.org 


Having used both parallel and serial tone MIL-STD-188-110A modems, I 
must admit that the serial tone modem appeared to be more robust. 
However, I really wonder if we (hams) need that robustness. We're 
talking about signals way down in the noise...channelized communications 
with known stations on the channel. I'm not sure this is really 

needed on the hambands. It would come in handy during the midst of a 
hurricane where the noise level is very high; but, we generally use 
slow speed CW (5-10 wpm) done here on the Texas Gulf Coast. 


I do not mean to stifle efforts in developing a serial tone modem... 
I'm just trying to be a little practical. As we say at Kelly AFB, 
"why buy a Cadillac when a Chevrolet will do". 


How about both...then we can "have our cake and eat it too". 


73, Walt 
From k5yfw@sacdm10.kelly.af.mil Sun Jul 16 19:02:23 1995 
Received: from sacdmi0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id TAA17509 for 
<hfsig@tapr.org>; Sun, 16 Jul 1995 19:02:16 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsXdYu-0001m6C; Sun, 16 Jul 95 18:57 CDT 
Message-Id: <mOsxXdYu-0001m6C@sacdm10.kelly.af.mil> 
Date: Sun, 16 Jul 95 18:57:27 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:475] Re: ANDVT TACTERM Documentation 
To: hfsig@tapr.org 
X-orig-date: Sat, 15 Jul 1995 10:45:19 -0500 
X-orig-from: Frode Weierud <frode@dxcern.cern.ch> 
X-orig-message-ID: <Pine.ULT.3.91.950715173400 .22055B-100000@dxcern.cern.ch> 


In Frode's message of 15 Jul 1995 at 1045 CDT, he writes: 
> What I really meant with my remark is that Pawel's multitone modem has 


> made it on HF. A few hams are now actively testing his modem on VHF and 
> HF. Just to let you see that things are moving extremely fast ahead. 

> 

> 73's Frode 


In the local youth vernacular..... Cool! -- wdd 
From chbrain@dircon.co.uk Mon Jul 17 01:31:37 1995 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id BAA24608 for 
<hfsig@tapr.org>; Mon, 17 Jul 1995 01:31:32 -0500 
Received: by felix.dircon.co.uk id AA13339 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Mon, 17 Jul 1995 07:31:27 +0100 
Message-Id: <199507170631.AA13339@felix.dircon.co.uk> 
Received: from ad044.pool.dircon.co.uk(193.128.231.44) by amnesiac via smap (V1.3) 
id sma013331; Mon Jul 17 07:30:56 1995 
X-Sender: chbrain@dircon.co.uk 
X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 


Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 17 Jul 1995 05:40:36 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Re: [HFSIG:476] Parallel vs Serial Tone Modems 


>I do not mean to stifle efforts in developing a serial tone modem... 
>I'm just trying to be a little practical. 


>73, Walt 

> 

> 

Hey, 

Walt we do things because they are there!!! Seriously I have been waiting for 


a discussion on serial tone modems. A simple slow speed modem appears to 

be quite do-able. The main problem is I think is the probable requirement 
to use 
multiple DSPs. 

I have been reading about the equalisers used in mobile radio modems, I guess 
the real difference is the actual multipath delays are much greater 
therefore longer 

equalisers are needed for H.F. 

Whether we use a training sequence or decision directed I cannot guess. 
However it may well be that a slow < 1kbit/s modem is more suitable for the ham 
environment especially something that is proof against those pesky CWers! 


Something like a 300 baud modem would be interesting with a simple equaliser 
in front of it. 


As far as receivers are concerned a nice project would be to take an I.F signal 
down convert it to say 10Khz then demodulate using DSP. I will have to 
investigate my TS850 as it does something like that for it's external DSP unit. 
(Although it just filters). 


Another thing would be an intelligent VOX with compression done in DSP 
could event have an expander at the far end. 


I must admit I have learn't a lot the last few months from this news group, my 
8ary modem is proceeding it has been re-written a couple of times due to 

my improving knowledge. My main problem currently is gaining and tracking 

bit sync. The sync has to lock as fast as possible. It should also have the 
ability to re-sync to a colliding signal this of course causes a problem! 

The technique I am using is to divide the tone with the highest power with 

that of the others. This produces a nice triangle wave. I then use an early/late 
gate to find the peak. This locks the NCO (thats the bit I can't get to work 
yet) 

the NCO then triggers an integrate and dump. At the end of the period a decision 
is made as to which tone was received. 


Regards Charles 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Mon Jul 17 02:27:25 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id CAA25375 for 
<hfsig@tapr.org>; Mon, 17 Jul 1995 02:27:11 -0500 
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th- 
darmstadt.de with SMTP id AA21050 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 17 Jul 1995 09:26:59 +0200 
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus 
(8.6.9/8.6.9-HRZ) with ESMTP id JAA17795 for <hfsig@tapr.org>; Mon, 17 Jul 1995 
09:26:58 +0200 
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id JAA15524 for 
hfsig@tapr.org; Mon, 17 Jul 1995 09:26:58 +0200 
Message-Id: <199507170726.JAA15524@hades> 
Subject: Re: Parallel vs Serial Tone 
To: hfsig@tapr.org 
Date: Mon, 17 Jul 1995 09:26:58 +0200 (MESZ) 
In-Reply-To: <199507170631.AA13339@felix.dircon.co.uk> from "Charles Brain" at Jul 
17, 95 01:34:38 am 
X-Mailer: ELM [version 2.4 PL24] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 2753 


Hi all! 


Thank you very much for the pleasant discussions during the last 
weeks. I like to contribute to the discussion of seriell vs. parallel 
type modems. This discussion is quite popular now in Germany 

an Europe as we are going to use a parallel type modem 

(coded OFDM) for broadcasting digital audio (DAB). There were 
several arcticles stating that single carrier transmissions are 
better in general. As our institute here does research work on 

OFDM this is of course not our opinion. Looking at HF there 

were a few comparisions of single tone modems to parallel tone ones. 
All this papers have in common that the modems are compared using 
no coding at all. This is not fair at all, as single carrier modems 
need a demodulation scheme that is somehow a form of coding. 

I think this is due to the fact that parallel tone modems 

are older than single carrier ones and therefore usually do 

not use advanced signal processing algorithms or coding. If you 
look at recent papers about parallel tone modems there is still 
enough to do. 

The only real drawback when using parallel tone modems is the 


limited mean power with peak power limited equipment. If you are 

using proper FEC schemes, both types should be comparable even at low 
BER. From the implementations point of view you need a considerebly 
higher complexity for single carrier modems than for parallel ones. 

If someone is interested in information look for articles 

from Clark, A.P. or for: Clark, A.P.: Adaptive Detectors for Digital 
Modems. Pentech Press, London 1989. He discusses several very interesting 
aspects of single carrier transmission on HF. 


So far no one has mentioned the advantages of parallel tone modems 
other than the relaxed complexity. We have a back channel from the 
receiving to the transmitting side which we can use for informing 
the transmitter of the channel conditions. The receiver could i.e. 
tell the transmitter, that one frequency bin is jammed, so that 
the transmitter can leave this bin empty. Try this with a single 
carrier modem... 


BTW. Can anybody make me a copy of the Mil-STD things? It is 
not so easy to get these things in Germany. Or is there maybe 
a Gopher server like for the CCITT? 


Alexander DL8AAU 


4 
| Alexander F. Kurpiers | 

| Institut £. Uebertragungstechnik | Voice: +49-6151-162369 

| u. Elektroakustik | Fax : +49-6151-165545 

| Merckstrasse 25 | EMail: a.kurpiers@uet.th-darmstadt.de 
| D-64283 Darmstadt (Germany) | Hamradio: dl8aau@db0eam.#thes.deu.eu 

+ 


From frode@dxcern.cern.ch Mon Jul 17 03:22:18 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id DAA26224 for 
<hfsig@tapr.org>; Mon, 17 Jul 1995 03:22:13 -0500 
Received: from dxcern.cern.ch by dxmint.cern.ch 
id AA12733; Mon, 17 Jul 1995 10:22:10 +0200 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AAQ5223; Mon, 17 Jul 1995 10:22:08 +0200 
Date: Mon, 17 Jul 1995 10:22:06 +0200 (MET DST) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:471] Re: ANDVT TACTERM Documentation 
In-Reply-To: <9507141724.AA15857@ucs.orst.edu> 
Message-Id: <Pine.ULT.3.91.950717092450 .2226A-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Fri, 14 Jul 1995, Johan Forrer wrote: 


In a document that I received from Phil Karn, it describes in a fair amount 
of detail, how one outfit did their own 16-tone MIL-STD-188 modem. They also 
had to deal with this same problem of using readily-available SSB rigs. 
Their solution was to use an audio band 935 - 2585 Hz for the tones. 


VVV WV 


Yes, this is the 16-tone modem from MIL-STD-188-110A, Appendix A. The 
interesting thing is that the ANDVT TACTERM modem is based on the 39 tone 
modem described in Appendix B. They are using the same preamble tones for 
both Doppler Preamble and Frame Sync preamble. The length of the 
preambles are not exactly the same though. And the 16 data tones have 
been extracted from the 39 tone set. 


I also believe that there is no question that a single tone system at low 
baud rate will outperform a parallel tone system (in terms of BER for any 
given s/n). However, in the end it becomes a tradeoff between speed and 
robustness. The parallel modem will certainly have the advantage for speed. 
I think one have to be careful when reading papers about these things 
without normalizing everything to the same units (BER for given S/N at 
bits/second/hertz). This is confusing. 


VVVVVV VV 


I agree it sometimes sounds confusing. I have no garantie that they did 
the normalization correct in this paper I referred to, but the results of 
the modem tests was plotted in the same diagram and as they used SNR 
instead of Eb/No (bit energy to noise-power spectral energy) I supposed 
they had normalized for bit rate and bandwidth. I would like to invite 
all of you to have a close look at Bernard Sklar's tutorial "Defining, 
Designing, and Evaluating Digital Communication Systems", IEEE 
Communications Magazine, Vol. 31, No. 11, Nov. 1993, pp.92-101. I find 
this an excellent paper in clarifying a somewhat convoluted subject. 


As I have already put on my teaching hat I will give you a few other 
literature pointers as well. First of all I should like to mention the 
paper by Joseph M. Perl, "Channel Coding in a Self-Optimizing HF Modem", 
Proceedings of the 1984 International Zurich Seminar on Digital 
Communications, March 6-8, 1984, (IEEE Catalog No. 84CH1998-4), 
pp.101-106. This is an interesting approach for designing an adaptive and 
optimizing HF modem. It can choose between four different modulation 
types: DPSK, DQPSK, FSK and MFSK, while the number of tones are equal or 
less than 49, baud rate equal of less than 100 Baud, in band diversity, 
error correcting codes (Golay 1/2; Majority, Convolutional 1/2, 1/3, 
1/4), interleaving delay equal or less than 4.5s, with hard and soft 
Viterbi decoder. 


The trick is of course the Link Quality Evaluation (LQE) which is based 
on analysis of the received information or on the preamble tones, hence 
no special link quality signaling is needed. The channel estimation 

does not take more than about 8% of DSP processor's resources. The 
channel evaluation techniques used are described in another paper, which 
I don't have the reference to where I am sitting at the moment. I can 
come back with that if there is an interest. 


Another paper that almost answers Pawel's questions about optimum symbol 


rates etc. is: Doron Rainish and Jospeh M. Perl, "Generalized Cutoff Rate 
od Time- and Frequency-Selective Fading Channels", IEEE Trans. on Comm., 
Vol. 37, No. 5, May 1989, pp.449-467. They look at optimal code rate and 
symbol element duration for MFSK and MDPSK in various HF channels. They 
also look at optimal guard time. An interesting thing is the special 
case for MDPSK over the CCIR HF channel, where the optimal guard times 
equals the multipath spread and is independant of SNR. The paper is at 
times rather heavy, but the final plots are very clear. 


The question of guard time is an interesting one. Ralph is rather 
sceptical to the value of using guard time, and the paper above also 
shows that the real value is somewhat dubious. One thing is sure and that 
it is a loss of signalling energy and that has to be weighted against 
what effect it can have on combating multipath spread. 


The question about what type of modem which is the optimal for amateur 

use is very difficult to answer as we have very diverse needs. Some of us 
only want to have a chat now and then and then a MFSK (a la Piccolo) 

modem should assure good performance under almost all conditions, while 
others are interested in moving large amount of data at high speed to tie 
together packet radio networks etc. For the high speed use both parallel 
tone and serial tone modems have their place and as Peter Reynolds', KE4BAD, 
paper "HF Channel Simulator Tests of Clover", QEX, December 1994, pp.7-12 
showed a serial tone modem like the one described in STANAG 4285 is a 

very serious contender. It clearly beats the Clover waveforms. 


73's Frode 
Frode Weierud Phone : 41 22 7674794 
CERN, SL Fax : 41 22 7679185 
CH-1211 Geneva 23, Switzerland E-mail : frode@dxcern.cern.ch 


From JALOCHA@chopin.ifj.edu.pl Mon Jul 17 05:32:08 1995 

Received: from nms (nms.cyf£-kr.edu.pl [149.156.1.3]) by dingus.n5lyt.datarace.com 
(8.6.12/8.6.9) with ESMTP id FAA26822 for <hfsig@tapr.org>; Mon, 17 Jul 1995 
05:32:02 -0500 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms 
(8.6.11/8.6.11) with SMTP id MAA11686 for <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>; 
Mon, 17 Jul 1995 12:31:24 +0200 

Date: Mon, 17 Jul 1995 12:21 GMT+1 

Subject: Re: [HFSIG:448] Re: HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <C84983ED6023255A@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


I am very pleased to annouce that I have made a useable modem's code 
with KISS interface. 


Just to remind you: 
My modem uses 15 tones spaced at 150 Hz. Each tone is DQPSK modulated 


at 100 baud. Total bit rate is thus 15*100*2 = 3000 bps. 

The modem auto-tunes to incoming packets within at least +/- 75 Hz 

( +/- 100 Hz is the absolute limit ). 

Optionally you can activate simple FEC: for every 11 data bits you add 4 
and afterwards you can correct single bit errors. 

Interleave is the other option: any reasonable factor can be specified. 


The modem is still missing frequency and symbol timing tracking during 
the data decoding phase. 

My initial tone's phases aren't very good either so I get 

peak/RMS = 4 (12 dB). 


So far I have only made a simple loopback tests and I get the following 
results: 


FEC off, S/N = 13 dB => 3/4 of 230 byte packets get through 
FEC on, S/N = 7 dB => 3/4 of 230 byte packets get through 


Don't take these results too serious, as the noise spectrum wasn't 
very flat... 

Noise and RMS measurements were done with a soundcard by recording 

the noise/signal and computing the RMS off-line. 

Packet loss rate was measured with JNOS by sending out regular beacons 
and looking up the number of received packets. 


There is a hope that the first on-air tests will be done this week 
by Timo and Joni from Finland. 


Pawel 
From FORRERIJ@frl.orst.edu Mon Jul 17 11:34:05 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id LAA31336 for 
<hfsig@tapr.org>; Mon, 17 Jul 1995 11:34:00 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id JAA20542 for <hfsig@tapr.org>; Mon, 17 Jul 1995 
09:32:38 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 17 Jul 95 9:39:06 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 17 Jul 95 9:38:42 
PST8PDT 
From: "Johan Forrer" <FORRERIJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 17 Jul 1995 09:38:34 PST8PDT 
Subject: Re: [HFSIG:474] CLOVER II vs. Pactor II 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <580223A120B@fr1l.orst.edu> 


Hi Rick, 


You pose some difficult questions. The probably are aware of a lot of 
claims are presently being made as well as some degree of 
personalities involved. I do not wish to add to the confusion, however, 
just add my two cents worth. 


I am of the opinion, at least as far as I can tell of this group 

of technically-minded participants, that all are interested in something 
that shows potential, however, without some common-sense evaluation 

or theoretical proof, who really knows what is better? 


There was a posting about a year or so ago from Rolf Sommerhalder about 
several systems that werer compared using an HF channel simulator - these 
included Pactor I and Clover II. There also was an interesting paper in QEX 
a while ago, mostly on Clover's capabilities - also done using a channel 
simulator. It may be worth your while finding these and perhaps it will give 
you a bit further insight - this the way how modems should be 

evaluated. From this you would want to see the BER vs. S/N curves. 


IMHO, the designers of Pactor I must be credited for clever innovation, 
basically on what was available at the time, i.e., 100 baud FSK. The 
protocol does, however, have a few snags. (a) a totally inappropriate 
synchronisation method, (b) no automatic link re-establishment after 
failure, (c) a flawed fall-back to lower rate when conditions are really 
bad. The claims of the designers regarding memory ARQ gain, was based on 
AWGN and not quite appropiate. Implementation of memory ARQ by other 
licencees not using any form of A/D is rather amusing. Pactor II has 
several innovative features such as stronger ECC and a new modulation. With 
this innovation comes new challenges - frequency accuracy needs closer 
tolerances - fallback procedures are getting more complex. Time will tell 
how practical it all will work out. I can only guess the results when a 
device like this is being used by a complete non-technical novice. 


I don't know how many folks have follwed the evolution of Clover from the 
early days of CCW? Again, my personal opinions - I have always have 

had a great deal of respect for Clover's principles and believe it to be 
superior to anything that we have had on the ham bands. That 

is due to its modulation format, ECC, and also the transmission 

protocol is well engineered. 


Of the two, Pactor II and Clover II, my personal opinion is that the 
Clover modulation is superior to Pactor II's (I think it may be possible 
to prove it theoretically by deriving each error function (Marqum Q)). 
Pactor II, however, probably have a stronger ECC. We will have to see how 
these two utilities plays off against each other, i.e., Clover's 
time/frequency diversity principles against Pactor II's convolution code. 


I still am aking the unpopular question: why have we not seen a 

technical disclosure of either Clover or Pactor's such as we have seen done 
for G-TOR for example (published in full in the 1994 DCC proceedings). I 
mean at a level sufficient that amateurs can evaluate how things are 

really working. 


Sorry that I cannot offer a clear answer - I am afraid I only add to 


the confusion. 
73's 


--Johan 


As far as I can see, not many of the particpants in this net will jump in 
to buy, but rather 


From k5yfw@sacdm10.kelly.af.mil Mon Jul 17 17:21:26 1995 
Received: from sacdmi0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id RAAQ5055 for 
<hfsig@tapr.org>; Mon, 17 Jul 1995 17:21:19 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsXySg-0001mUC; Mon, 17 Jul 95 17:16 CDT 
Message-Id: <mOsxXySg-0001mUC@sacdm10.kelly.af.mil> 
Date: Mon, 17 Jul 95 17:16:26 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:478] Re: Parallel vs Serial Tone Modems 
To: hfsig@tapr.org 
X-orig-date: Mon, 17 Jul 1995 01:34:44 -0500 
X-orig-from: chbrain@dircon.co.uk (Charles Brain) 
X-orig-message-ID: <199507170631.AA13339@felix.dircon.co.uk> 


Charles, 


In your message of 17 Jul 1995 at 0134 CDT, you write: 


a discussion on serial tone modems. A simple slow speed modem appears to 
be quite do-able. The main problem is I think is the probable requirement 
to use 

multiple DSPs. 


> 

> >I do not mean to stifle efforts in developing a serial tone modem... 
> >I'm just trying to be a little practical. 

> >73, Walt 

>> 

>> 

> Hey, 

> Walt we do things because they are there!!! Seriously I have been waiting for 
> 

> 

> 

> 


VV VV VV VV VV 


VV VV VV VV VV VV VV VV VV VV VV OV 


VV VV VV VV 


Vv 


Rgr Rgr...don't let me slow you down and if I can duplicate 
your effort, rest assured I will. 


I have been reading about the equalisers used in mobile radio modems, I guess 
the real difference is the actual multipath delays are much greater 
therefore longer 

equalisers are needed for H.F. 

Whether we use a training sequence or decision directed I cannot guess. 
However it may well be that a slow < 1kbit/s modem is more suitable for the ham 
environment especially something that is proof against those pesky CWers! 


Something like a 300 baud modem would be interesting with a simple equaliser 
in front of it. 


No doubt about the need for a xveryx robust modem for those 
occasions when the noise is high and/or the signal is low and 
you need to get a message thru, then this type of modem would 
be nice. Its something we might use here on the Texas Gulf 
Coast during a hurricane. 


As far as receivers are concerned a nice project would be to take an I.F signal 
down convert it to say 10Khz then demodulate using DSP. I will have to 
investigate my TS850 as it does something like that for it's external DSP unit. 
(Although it just filters). 


Another thing would be an intelligent VOX with compression done in DSP 
could event have an expander at the far end. 


I must admit I have learn't a lot the last few months from this news group, my 
8ary modem is proceeding it has been re-written a couple of times due to 

my improving knowledge. My main problem currently is gaining and tracking 

bit sync. The sync has to lock as fast as possible. It should also have the 
ability to re-sync to a colliding signal this of course causes a problem! 

The technique I am using is to divide the tone with the highest power with 

that of the others. This produces a nice triangle wave. I then use an early/late 
gate to find the peak. This locks the NCO (thats the bit I can't get to work 
yet) 

the NCO then triggers an integrate and dump. At the end of the period a decision 
is made as to which tone was received. 


Regards Charles 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


Keep up the good work and say HOWDY, to all tha hams at the 

Chelmsford Radio club and the Marconi folks. I really miss GOAEH, 

Albert, from Blackmoore/Hook-End...he was a very nice fellow. 

From muphaus@cris.com Mon Jul 17 17:52:27 1995 

Received: from deathstar.cris.com (deathstar-fddi.cris.com [199.3.12.171]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAAQ5799 for 
<hfsig@tapr.org>; Mon, 17 Jul 1995 17:52:23 -0500 

Received: from viking.cris.com by deathstar.cris.com [1-800-745-CRIS (voice) ] 
Errors-To: Muphaus@cris.com 

Received: by viking.cris.com (4.1) id AAQ8712; Mon, 17 Jul 95 18:52:11 EDT 
From: muphaus@cris.com (Marv Uphaus) 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:482] Re: CLOVER II vs. Pactor II 

Date: Mon, 17 Jul 1995 17:16:24 -0500 

Organization: Not Organized 

Reply-To: muphaus@cris.com 

Message-Id: <4EuCwM82cese083yn@cris.com> 

References: <580223A120B@frl.orst.edu> 

In-Reply-To: <580223A120B@frl.orst.edu> 

Lines: 73 


Johan... 
On Mon, 17 Jul 1995 11:44:13 -0500, you wrote: 


>I am of the opinion, at least as far as I can tell of this group 

>of technically-minded participants, that all are interested in something 
>that shows potential, however, without some common-sense evaluation 

>or theoretical proof, who really knows what is better? 


I just want to add some thoughts of my own... 


A commonly held opinion of hams is "What's my discount"... Hams always 
want the cheapest, bestest thing they can get... Several things come into 
play here... Cheap, if it works, will always win out over expensive... 
This has been, IMHO, the reason Clover has not taken off... This new 
Clover board may be the breakthrough that Clover needs... But $395 is 
still a lot... Look at the DigiCom packet stuff for the Commodore... That 
stuff is still running around the world... Good and cheap... Look at the 
success of BayCom... Look at the success of Pactor I... I tuned around 
recently on a weekend on 20 meters and Pactor I is the only thing that I 
heard... Why was it successful... It was pretty cheap and everyone had 
it... Once AEA and MFJ and Kantronics all put it in their products it 
became a standard... Until somebody besides HAL sells Clover it will never 
gain popularity, even if it is 1000 times better... G-TOR has a good 
chance since it is being licensed... 


None of this stuff is going to ever be popular on Ham Radio unless someone 


opens up the licensing... We would probably not have packet radio now if 
it hadn't been for TAPR... All the current popular modes on ham radio are 
open technically and copyright wise... The great success of the IBM PC had 


largely to do with the open architecture of the buss... The only good 


thing IBM ever did for the computer community, in my mind... (Don't flame, 
I won't read or respond...) 


>I still am aking the unpopular question: why have we not seen a 

>technical disclosure of either Clover or Pactor's such as we have seen done 
>for G-TOR for example (published in full in the 1994 DCC proceedings). I 
>mean at a level sufficient that amateurs can evaluate how things are 
>really working. 


One of the things that I hope will come out of this group is a definitive 
statement concerning a good CHEAP way for amateurs to communicate digitally 
via HF... I think that we are on the way... I hope when something is 
decided that TAPR might pick up the ball again... I think that using the 
sound cards is a BIG step forward... This group ought to be the ones to 
put together the digital basis for HF communications into the 21st 
century... Something that any moderately technical ham can get running 
for less than $200... 


I have an old HAL RTTY modem, a CRI-200, I found at a hamfest for $45... 
That and BMK Multy got me on RTTY, PACTOR, AMTOR for less than the $200... 
I would do it again... We need this kind of thing for advanced HF digital 
and I am convinced that it is do-able... Johan is there with the PC-TOR 
stuff, but it needs to be with the more robust error correcting and higher 
data speeds... Lets keep pushing forward...!!! 


In the mean time Internet Relay Chat and E-Mail on the Internet is taking 


over the role of digital communications via ham radio... And on IRC you 
don't have to know the code or take an FCC test... There are thousands of 
technically competent folks using that now, who could be hams... There's 


even a ham radio area (4#hamradio) on IRC, populated by a BOT and people... 


We need to move forward or ham radio is going to flounder and forever be 
gone...!!! I'm on the Internet every day and on ham radio very rarely... 
I don't want to see it go, but I think that it's demise is getting 
closer... 


73... Marv... K4BVG 


In the midst of great joy, do not promise anyone anything. In the midst of 
great anger, do not answer anyone's letter. - Chinese Proverb 


-- Marv Uphaus -- muphaus@cris.com -- finger for PGP public key -- 
From esilbaug@hawkeye Wed Jul 19 15:36:02 1995 
Received: from hawkeye (moss.afit.af.mil [129.92.100.150]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id PAAQ3145 for 
<hfsig@tapr.org>; Wed, 19 Jul 1995 15:35:58 -0500 
Received: from atilla.afit.af.mil by hawkeye (4.1/SMI-4.1) 
id AAQ3120; Wed, 19 Jul 95 10:39:59 EDT 
Date: Wed, 19 Jul 95 10:39:59 EDT 
From: esilbaug@hawkeye (Eric Silbaugh) 
Message-Id: <9507191439 .AA03120@hawkeye> 
To: hfsig@tapr.org 
Subject: Re: Parallel vs Serial Tone 


Cc: esilbaug@afit.af.mil 


Here is a reference for those of you interested in comparing the COFDM 
and single-tone techniques which Alexander, DL8AAU, discussed in his 
recent posting. 


H. Sari, G. Karam, I. Jeanclaude, "Transmission techniques 
for digital terrestrial TV broadcasting", IEEE Communications 
Magazine, February 1995, pp.100-109. 


The authors begin with an overview of OFDM and channel equalization. 
It turns out that OFDM is very similar to a single-tone system using 
frequency-domain equalization. This was interesting since most 
equalization techniques I have seen (including those used in the 
single-tone MIL-STD modems) work in the time-domain. In retrospect 
I guess it shouldn't be surprising that equalization can be done in 
the frequency-domain considering all the time-frequency dualities 

in Fourier analysis. 


Next the authors have a simple derivation showing why OFDM is 
extremely sensitive to frequency offsets. I accidentally ran into 
this when I mis-typed a sampling frequency in the peak-to-RMS 
amplitude simulations I worked on a few months ago. Energy spilling 
into adjacent FFT bins like they were leaky buckets! I hate when 
that happens. Pawel seems to have discovered this empirically; which 
is why his modem has auto-tuning. 


In the next section the authors present the results of some computer 
simulations showing that losses produced by frequency offsets and 
power backoff (due to the high peak amplitudes) in OFDM produce BERs 
much larger than those of an equalized simgle-tone system. 


One observation the authors make is that frequency selective fading 
produces an irreducible BER in OFDM systems not using forward error 
correction (FEC). Which leads to their last results showing that an 
OFDM system with FEC, coded OFDM (COFDM), can produce BERs identical 
to or slightly better than an equalized single-tone system (without 
FEC). At the very least this shows the power, and necessity, of FEC! 


One unanswered question is the relative implemention complexity 

(DSP cycles) of COFDM versus single-tone modulation with frequency - 
domain equalization. All the time domain equalizers I have seen are 
tremendous cycle hogs (not the Harley-Davidson kind either). I 
wonder if frequency-domain equalization is any easier. Can a DSP 
sound card handle it? 


It also seems that performance of the single-tone modem could be 
improved by adding FEC. Of course, this would require even more DSP 
cycles, unless the host computer does the FEC decoding. 


COFDM would seem to have the initial advantage in reduced complexity 
(please correct me if this is wrong). Past examples of working 


systems show that it can be done. As long as the carrier tracking 
and high peak power limitations can be overcome it looks like this 
could produce a robust system. 


As others have noted a fairly inexpensive, robust, moderate speed 
HF modem will be a big step forward. Basing it on DSP just means it 
can be improved without buying new hardware. Keep up the good work! 


Eric, N2NNP 


By as ay Eric E. Silbaugh 
3 sist esilbaug@afit.af.mil 


: 2 All standard, non-standard, and 

Doe Rca eet eee MIL-STD disclaimers apply 
From FORRERJ@frl.orst.edu Wed Jul 19 16:18:34 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id QAAQ3775 for 
<hfsig@tapr.org>; Wed, 19 Jul 1995 16:18:14 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
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13:18:22 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Wed, 19 Jul 95 13:23:22 PST8PDT 

Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 19 Jul 95 13:23:19 
PST8PDT 
From: "Johan Forrer" <FORRERIJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Wed, 19 Jul 1995 13:23:19 PST8PDT 
Subject: FCC Regulations for HF digital 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <5B3E2247CF4@frl.orst.edu> 
Hi all, 


Attached is a bit of information that should be of importance to all. 
Thanks to Rick for allowing me to post it: 


Hi Rick, 


I'm pleased that you bring this up as I was in the process of doing it 
myself. This is a topic that should be addressed rather carefully and 
diplomatically - historically there have been great differences of opinion 
about this very topic. 


>Johan, 
>I have been following the HFSIG and one thing bothers me. With all the 


>talk of total occupied bandwidth what is the limit for HF? Do we really 
>have SSB type bandwidths to play with? For some reason I thought we were 
>limited to 300 baud and a maximum peak to peak deviation of 1 KHz under 
>30 MHz. By Carson's rule this is approximately 

>2x* (500+300)=1.6 KHz of bandwidth. Is this right? 


Correct - that is roughly how I interpret part 97 as well. One further 
point that is often forgotten, is that part 97 also specifies which code 
alphabet (i.e. ASCII or BAUDOT). The latter has clearly been violated by 
modern digital modes - Clover for instance by using ECC, Pactor and G-TOR 
when using data compression - just a technicality that have never legally 
been challenged. This, however, is if you interpret the law to the 

letter. Clearly, however, the mentioned violations are not serious, and as 
a matter of fact not intentional encryption. One might argue that it is done 
all the time - that is not how part 97 is written - I suspect 

that the matter about the code alphabets will rest unless challenged. IMHO, 
it will be a total waste of time and resources if it does become a legal 
issue. 


I would rather see that our FCC regulations regarding the digital modes be 
brought up to date with the UK and German regulations, or otherwise to keep 
track with modern technology. 


>Next Question. If 1.6 KHz is right, why does Clover fit into 500 Hz? Are 
>we required to use CW type bandwidths? If not, then why bother with such 
>tight restrictions since wider bandwidth is (probably) easier to use 
>effectively...except for the CW interference problems. 

>Thanks 

>Rick W6NZK 


>Rick Booth 
>E-mail: rick@itron-ca.com 


That is a real issue. 


Yes, Clover technically fits into a 500 Hz slot - Pactor II's waveform is 
also shaped to fit in a 500 Hz slot. This pretty much follows a belief 
that narrow-band emissions conserve spectral space. 


With the new high speed modems coming along, something inevitably will have 
to happen. I hope that this evolution happens in a way that will have the 
least amount of negative impact. I do suspect, however, that the notion 
will be fought every inch of the way. In short, yes, we probably can 
squeeze a number of orthogonal channels into 1 KHz and comply to the 
present regulations. It would be better than anything we have at the 
moment, but not a good long term solution. 


It should be our mission to convince the digital community to support our 


efforts. I don't think that many know what we are intent on putting on the 
air, i.e., network vs keyboarding, modulation format and it's occupied 
bandwidth. The concepts must be formalized in clear language. 


Without spending to much time phrasing this correctly - this is 
what I had thought about (of course without saying - open for debate, my 
own personal opinions): 


First, we have to show that we have superiour technology, i.e., 
it gets traffic through, even under adverse conditions without 
making dreaded demands on spectral usage. Instead of beating 300 
baud packet to death, we need to illustrate an effective 
alternate solution. 


Second, we have to convincingly show that narrow-band emissions are 
as prone (probably more) to causing interference and suffering from 
interference than does our proposed wide-band emissions. This holds 
for man-made, or HF propagation wise. 


For an interesting aside: the argument that the famous John Costas 
had to defend when he was making attempts to convince 

the IEEE of why wide-band emissions, was quite similar - 

this was when spread-spectrum communications was born. I am certain 
that I don't have the vision and influence that Costas had, but it 
is only a matter of time. You already know the outcome of that one. 


To help the argument along, just for starters consider the 
following: The impact on other nearby stations for a digital 
modulated 100W packed into 500 Hz (0.2W/Hz) compared to 

100W spead over 3KHz (0.033W/Hz). Even with the best filters, 

how wide will a high-powered signal really be? The main concern 
that I have regarding wider bandwidth emissions is when an operator 
indiscriminantly puts a big linear behind such a signal - this 
would be disasterous and counterproductive. 


The notion of low power/Hz, and ideally lots of Hz, is what it's 
all about. The wider it gets, the better it gets (give and 

take a bit of liberty). Our present parallel modems does not 

use a speading function as in SS yet - at the very highest 

rate it needs all the bandwidth, but at lower rate 

frequency diversity is used, in which case bandwidth is 

used with redundancy. 


Another example: Would the principle ideas as used in the cellular 
phone market have worked if it was based on narrow-band 
transmission? 


What is needed is an effective demonstration of what we are 
intending to use and win the support of the digital community. 


The real issue and crux of the matter is how to best utilize 


our allocated spectrum by a number of simultaneous users without 
QRM (leave poor operator judgement aside for the moment). Weigh 
the advantage of replacing the current HF digital networks with an 
efficient shared-channel mode. 


I expect that this issue will stir up a lot of discussion. This is an 
invitation to hear your views on how this should be approached. 


73's 
--Johan 


From wd5ivd Wed Jul 19 21:21:57 1995 

Received: (from wd5ivd@localhost) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) id 
VAA10073 for hfsig@tapr.org; Wed, 19 Jul 1995 21:21:15 -0500 

From: Greg Jones <wd5ivd> 

Message-Id: <199507200221.VAA10073@dingus.n5lyt.datarace.com> 

Subject: Re: [HFSIG:486] FCC Regulations for HF digital 

To: hfsig@tapr.org 

Date: Wed, 19 Jul 1995 21:20:54 -0500 (CDT) 

In-Reply-To: <5B3E2247CF4@frl.orst.edu> from "Johan Forrer" at Jul 19, 95 05:22:28 
pm 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 4283 


Hi Johan -- has anyone checked the rules very recently. In a thread 
on netsig we had this posted. 


>> EVERYBODY is using AX.25 because the FCC says you MUST. 

> 

>The AX.25 requirement has been gone for about a year, and I didn't hear 
>about it when it happened either. 

> 

>This is the new 97.109e: 


(e) No station may be automatically controlled while transmitting 
third-party communications, except a station participating as a 
forwarding station in a message forwarding system. 


VV VV WV 


>This paragraph used to contain the AX.25 requirement. It's gone. 
> 
> Bruce Perens 


While this does not direclty impact HF modes, it does impact networking and 
BBS operations. 


The main point is that the FCC, when aware of something needing to be done, 
will change the rules when a section is open. 


So - we should think about talking to the 

TAPR FCC Reg committee and some of the people at the league about this issue 

so that they can be aware of it. I would think that Paul Rinaldo is aware of it 
-- the reason that many of the alternate protocols/modes were published 

in the last Digital Communications Conferecne Proceedings was to be able to 

have a reference to then include under some 'misc' section of the rules. 


I forget all the manuvers required. Phil is on the Future Systems 
Committe and might be able to comment....?? 


First, we have to show that we have superiour technology, i.e., 
it gets traffic through, even under adverse conditions without 
making dreaded demands on spectral usage. Instead of beating 300 
baud packet to death, we need to illustrate an effective 
alternate solution. 


Second, we have to convincingly show that narrow-band emissions are 
as prone (probably more) to causing interference and suffering from 
interference than does our proposed wide-band emissions. This holds 
for man-made, or HF propagation wise. 


The real issue and crux of the matter is how to best utilize 

our allocated spectrum by a number of simultaneous users without 
QRM (leave poor operator judgement aside for the moment). Weigh 
the advantage of replacing the current HF digital networks with an 
efficient shared-channel mode. 


I expect that this issue will stir up a lot of discussion. This is an 
invitation to hear your views on how this should be approached. 


VVVVV VV VV VV VV VV VV VV VV VV WV 


This will indeed be an interesting debate in the future. It already has 
been. 


Personally, I think we continue to improve the technology. If we can make 
HF communicatins work at better rates with better reliability I think we MUST 


advance the state of the amateur art. 


The problem is that you can spend lots of time worrying about others. While 


all efforts should be made to communicate the technical advances -- for 
every amateur willing to listen and understand there will be two more 
sending flames. However unfortunate -- a common amateur trait. All of 


amateur history is filled with examples: ssb/am, etc. 


The golden rule of amateur radio -- "those that develop hardware or software 
‘rule'" Pretty simple. If you develop something that works better, faster, 
and hopefully (for most hams) cheaper :-) then no matter how much yelling, 
people will start to use it. Will it impact others -- yes. Like any mode in 
amateur radio. 


However, limitation of modes or speeds is not the correct manner in 
which to enforce better operating correctness. 


The problem is that it is easier to regulate then educate. Amateurs might 
be good at communications technology, but are in general terms poor 
communicators. 


Well, I'll get off my soap box. 


I hope the HF SIG keeps up the advancement of the amatuer art. The rules 
will eventually sort them self out. We can work with the FCC to make sure 
that what we are doing is seen as within the scope of the rules. 


I must congratulate everyone on this SIG. I feel that this is one of the 
best SIGs we have in TAPR. The level of discussion and technical research 
is terrific to see happening! Hats off to Johan and everyone else. 


Cheers - Greg, WD5IVD 
From FORRERJ@frl.orst.edu Thu Jul 20 12:19:21 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id MAB10999 for 
<hfsig@tapr.org>; Thu, 20 Jul 1995 12:19:10 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id KAA10207 for <hfsig@tapr.org>; Thu, 20 Jul 1995 
10:19:11 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Thu, 20 Jul 95 10:24:11 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 20 Jul 95 10:24:08 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 20 Jul 1995 10:24:00 PST8PDT 
Subject: FFC part 97 on WWW? 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <5C8E62F48E5@frl.orst.edu> 
Hi, 


Does anyone know whether the FCC have a WEB page and whether 
perhaps the latest reg's are available in electronic form? 


Thanks in advance, 


--Johan, KC7WW 
From mcdermot@eagle.aud.alcatel.com Thu Jul 20 15:39:39 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id PAA14668 for 
<hfsig@tapr.org>; Thu, 20 Jul 1995 15:39:34 -0500 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 

id AA29464; Thu, 20 Jul 95 15:39:31 CDT 


Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 

id AAQ1771; Thu, 20 Jul 95 15:39:30 CDT 
Date: Thu, 20 Jul 95 15:39:30 CDT 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9507202039.AA01771@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:485] Re: Parallel vs Serial Tone 


Eric Silbaugh brings up several good points in the debate on multi-carrier 
vs. Single carrier modulation (will this become the SSB vs. AM war of the 
1990's ?) 


In the next section the authors present the results of some computer 
simulations showing that losses produced by frequency offsets and 
power backoff (due to the high peak amplitudes) in OFDM produce BERs 
much larger than those of an equalized simgle-tone system. 


VV VV WV 


It should be noted that high orders of modulation on single 
carrier transmission (such as 64 QAM, etc.) also require a great 
deal of linearity in the transmitter. It can become debateable as 
to which modulation format imposes the more severe linearity requirement! 


One observation the authors make is that frequency selective fading 
produces an irreducible BER in OFDM systems not using forward error 
correction (FEC). Which leads to their last results showing that an 
OFDM system with FEC, coded OFDM (COFDM), can produce BERs identical 
to or slightly better than an equalized single-tone system (without 
FEC). At the very least this shows the power, and necessity, of FEC! 


VVVV VV MV 


With HF, time-diversity is an easily achievable diversity (and 
with HF, any kind of diversity helps greatly!). Recent work on single 
carrier modems has focused on equalization using minimization of the 
Viterbi error metric, rather than minimization of the ISI, as a good 
variable to reduce when adjusting the adaptive equalizer. This of 
course presumes convolutionally coded data. Not sure which modulation 
format requires the greater computational load for equalization. Custom 
silicon does this very well in HDSL and ADSL land-line systems, and the 
equalizers are big. 


One unanswered question is the relative implemention complexity 

(DSP cycles) of COFDM versus single-tone modulation with frequency - 
domain equalization. All the time domain equalizers I have seen are 
tremendous cycle hogs (not the Harley-Davidson kind either). I 
wonder if frequency-domain equalization is any easier. Can a DSP 
sound card handle it? 


It also seems that performance of the single-tone modem could be 
improved by adding FEC. Of course, this would require even more DSP 
cycles, unless the host computer does the FEC decoding. 


VV VV VV VV VV 


COFDM would seem to have the initial advantage in reduced complexity 
(please correct me if this is wrong). Past examples of working 
systems show that it can be done. As long as the carrier tracking 
and high peak power limitations can be overcome it looks like this 
could produce a robust system. 


As others have noted a fairly inexpensive, robust, moderate speed 
HF modem will be a big step forward. Basing it on DSP just means it 
can be improved without buying new hardware. Keep up the good work! 


VV VVV VV VV VV VV VV VV VV VV 


Eric, N2NNP 
ie =" ie Eric E. Silbaugh 
: sen ae esilbaug@afit.af.mil 
: ar All standard, non-standard, and 
meh cee Sietentee ce Soe tease MIL-STD disclaimers apply 
wee eee ee ee ee ew ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee Si 
Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 
[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 
[ June 23-27, 1996, Dallas, Tx. ] | 
ee Si 


From k5yfw@sacdm10.kelly.af.mil Thu Jul 20 17:39:14 1995 
Received: from sacdmi0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id RAA17057 for 
<hfsig@tapr.org>; Thu, 20 Jul 1995 17:39:02 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOsZ4AL-0001zcC; Thu, 20 Jul 95 17:34 CDT 
Message-Id: <mOsZ4AL-0001zcC@sacdm10.kelly.af.mil> 
Date: Thu, 20 Jul 95 17:34:00 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:488] FFC part 97 on WWW? 
To: hfsig@tapr.org 
X-orig-date: Thu, 20 Jul 1995 12:39:26 -0500 
X-orig-from: "Johan Forrer" <FORRERJ@frl.orst.edu> 
X-orig-message-ID: <5C8E62F48E5@frl.orst.edu> 


Johan, 


In your message of 20 Jul 1995 at 1239 CDT, you write: 
> Hi, 


Does anyone know whether the FCC have a WEB page and whether 
perhaps the latest reg's are available in electronic form? 


VV VV 


> Thanks in advance, 
> 

> --Johan, KC7WW 

> 


For the FCC try: 
http: //fcc.goc:70/O0h/AAA_HOMEPAGE.htlm ox http://www.fcc.gov 
For Part 97 (the ARRL Official Copy) Try: 
http: //www.acs.oakland.edu/barc/arrl/part97.html 

or ftp arrl.org and I think you can ftp down part 97. 
I have visited www.acs.oakland.edu. 


Walt 

From chbrain@dircon.co.uk Tue Jul 25 14:54:29 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id OAA03010 for 

<hfsig@tapr.org>; Tue, 25 Jul 1995 14:54:21 -@500 

Received: by felix.dircon.co.uk id AA26597 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 25 Jul 1995 20:54:05 +0100 

Message-Id: <199507251954.AA26597@felix.dircon.co.uk> 

Received: from ac034.pool.dircon.co.uk(193.128.230.34) by amnesiac via smap (V1.3) 
id sma026595; Tue Jul 25 20:53:51 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 25 Jul 1995 19:02:00 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 

Subject: Fed Std 1052 


Hi, 

Does anyone know the current standing of Fed-Std 1052 Appendix B 
I think (The data link protocol). I have a 1992 version of it I was just 
wondering 

if it has moved from proposed to an actual standard. I am also interested in 
Fed-Std 1047, it was mentioned in QEX a few months back, I would like to read 
it, need something to help me sleep at night. 

There must be a way of finding out which standards are current. 


Another thing anyone managed to get IIR filters to work on a TMS320C50 all 
mine oscillate. I have been using PC-DSP to generate the coefficients and the 
code in the TI C50 databook, all I get get is wonderful oscillation! 


Regards Charles. 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From alanb@tsnake2.sr.hp.com Tue Jul 25 15:13:03 1995 

Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by 

dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id PAAQ3263 for 

<hfsig@tapr.org>; Tue, 25 Jul 1995 15:11:27 -0500 

Received: from hpmwtd.sr.hp.com by relay.hp.com with SMTP 
(1.37.109.16/15.5+ECS 3.3) id AA153112965; Tue, 25 Jul 1995 13:09:25 -0700 

Received: from algae.sr.hp.com by hpmwtd.sr.hp.com with SMTP 
(15.11.1.6/15.5+ECS 3.3) id AAQ6738; Tue, 25 Jul 95 13:09:18 -0700 

Received: by tsnake2.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ56022955; Tue, 25 Jul 1995 13:09:15 -0700 

From: Alan Bloom <alanb@tsnake2.sr.hp.com> 

Message-Id: <199507252009.AA056022955@tsnake2.sr.hp.com> 

Subject: Bandwidth of digital modulation 

To: hfsig@tapr.org 

Date: Tue, 25 Jul 1995 13:09:14 -0800 (PDT) 

X-Mailer: ELM [version 2.4 PL21] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Length: 4466 

Content-Transfer-Encoding: 7bit 

Content-Transfer-Encoding: quoted-printable 


I ftp'd an up-to-date (April 26, 1995) copy of part 97 from oak.oakland.e= 
ae well hidden: /pub/hamradio/arrl/infoserver/rib/part97.txt 

The bottom line is that there are no explicit bandwidth limitations below= 
28 MHz. There is a maximum FSK shift of 1 kHz and a maximum symbol rate = 
of 300 baud -- I suspect that the FCC expected that would impose a = 

de facto bandwidth limitation based on 97.307(a), but they were = 


probably not thinking about multi-carrier modulation! 


AL N1AL 


Subpart D--Technical Standards 
SDF ci % 


S 97.305 Authorized emission types. 
=2E... 


[Lists legal modulation modes for each frequency sub-band, = 
with footnotes referencing paragraphs in section 97.307(f)] 
S 97.307 Emission standards. 
(a) No amateur station transmission shall occupy more bandwidth than = 


necessary for the information rate and emission type being transmitted, i= 
n= 


accordance with good amateur practice. 
=2E... 
(£) The following standards and limitations apply to transmissions on = 


the frequencies specified in S 97.305(c) of this Part. 


[Phone bands below 29.0 MHz: ] 
(1) No angle-modulated emission may have a modulation index greater 


than 1 at the highest modulation frequency. 


[Phone bands below 225 MHz: ] 
(2) No non-phone emission shall exceed the bandwidth of a = 


communications quality phone emission of the same modulation type. The = 


total bandwidth of an independent sideband emission (having B as the firs= 
t= 


symbol), or a multiplexed image and phone emission, shall not exceed that= 


of a communications quality A3E emission. 
[CW bands below 28 MHz:] 
(3) Only a RTTY or data emission using a specified digital code liste= 


in S 97.309(a) of this Part may be transmitted. The symbol rate must not= 


exceed 300 bauds, or for frequency-shift keying, the frequency shift = 
between mark and space must not exceed 1 kHz. 
[28-28.3 MHz: ] 


(4) Only a RTTY or data emission using a specified digital code liste= 


in S 97.309(a) of this Part may be transmitted. The symbol rate must not= 


exceed 1200 bauds. For frequency-shift keying, the frequency shift betwee= 
n= 


mark and space must not exceed 1 kHz. 


[50.1-54 MHz, 144.1-148 MHz:] 
(5) A RTTY, data or multiplexed emission using a specified digital = 


code listed in S 97.309(a) of this Part may be transmitted. The symbol = 


rate must not exceed 19.6 kilobauds. A RTTY, data or multiplexed emissio= 
n= 


using an unspecified digital code under the limitations listed in S = 


97.309(b) of this Part also may be transmitted. The authorized bandwidth = 
is = 


20 kHz. 


[222-225 MHz, 420-450 MHz: ] 
(6) A RTTY, data or multiplexed emission using a specified digital = 


code listed in S 97.309(a) of this Part may be transmitted. The symbol ra= 
te = 


must not exceed 56 kilobauds. A RTTY, data or multiplexed emission using = 
an = 


unspecified digital code under the limitations listed in S 97.309(b) of 
this Part also may be transmitted. The authorized bandwidth is 100 kHz. 


[Amateur bands above 902 MHz:] 
(7) A RTTY, data or multiplexed emission using a specified digital 


code listed in S 97.309(a) of this Part or an unspecified digital code = 
under the limitations listed in S 97.309(b) of this Part may be = 
transmitted. 


[51-54 MHz, 144.1-148 MHz, >222 MHz: ] 
(8) A RTTY or data emission having designators with A, B, C, D, E, F= 


i 


G, H, J or R as the first symbol; 1, 2, 7 or 9 as the second symbol; and = 
D = 


or W as the third symbol is also authorized. 

=2E... 
[Paragraphs 9, 10, and 11 deal with novice CW privileges and 
phone operation in regions 1 and 3.] 


[>902 MHz: ] 
(12) Emission F8E may be transmitted. 


[219-220 MHz:] = 
(13) A data emission using an unspecified digital code under the = 


limitations listed in =A7 97.309(b) of this Part also may be transmitted.= 


The authorized bandwidth is 100 kHz. = 


S 97.309 RTTY and data emission codes. 


(a) [Specifies legal codes: 5-unit Baudot, 7-unit AMTOR, 7-unit ASCII= 


(b) Where authorized by S S 97.305(c) and 97.307(£) of this Part, a = 


station may transmit a RTTY or data emission using an unspecified digital= 


code, except to a station in a country with which the United States does = 
not have an agreement permitting the code to be used. RTTY and data = 


emissions using unspecified digital codes must not be transmitted for the= 


purpose of obscuring the meaning of any communication. 
[end] 


From FORRERJ@frl.orst.edu Tue Jul 25 15:44:05 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id PAAQ3641 for 
<hfsig@tapr.org>; Tue, 25 Jul 1995 15:43:58 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id NAAO4015 for <hfsig@tapr.org>; Tue, 25 Jul 1995 
13:43:40 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 25 Jul 95 13:48:53 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 25 Jul 95 13:48:31 
PST8PDT 
From: "Johan Forrer" <FORRERIJ@fr1l.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Tue, 25 Jul 1995 13:48:24 PST8PDT 
Subject: Re: [HFSIG:491] Fed Std 1052 
Priority: normal 
X-mailer: PMail v3.0 (Ria) 


Message-ID: <64451CC67CO0@fr1l.orst.edu> 
Hi Charles, 


Re: IIR filters. If you have a pole(s) close to the unity circle that may 
happen. Also if you are aiming for very high Q's, i.e., narrow passbands 
with brickwall filters, this may lead to that situation. For IIR 

filter architectures, part of the filter's output is determined 

both by past input as well as past output. It is not difficult to see that 
it doesn't take much to get the output history overpower the output 
history. Typically, once oscillation starts, you may even take the input to 
zero and it will merrily feed back output history and maintain the 
oscillatory state. The dampening factor is supposed to take care of 

this. 


Just a thought: do you clear the input and output history on 

initialization, or do you just leave use the garbage that is in memory? 

Does it start up OK and starts oscillation only when it sees a large signal? 
In the W9IGR software, you can quite easily get the IIR input filter to 
saturate by driving the audio input to hard, however, there is sufficient 
dampening to recover - one can see it return to normal, however like 

slow release AGC. 


Numerical roundoff error is another issue that may add to your problem: 
Since you only have a limited wordsize to work with, it is inevitable that 
you will encounter roundoff errors for each result that is computed. 
Right? The bad news is that each roundoff error are fed back and used as 
part of the input to the filter on the next round, so you have these 
errors in a recursive positive feedback loop! Certainly not an additive 
noise source like for instance FIR filters. 


There are several IIR filter designs around. Those that use an analog 
counterpart, does pre-warping, and then the transformation. This is a 
common way of doing them and I suspect that is what you may be using. There 
are some other exotic means of designing IIR filters, though I have never 
attempted that. 


I don't know whether this helped. Good luck anyway. 
--Johan, KC7WW 


From chbrain@dircon.co.uk Wed Jul 26 00:40:02 1995 

Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 

dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id AAA11838 for 

<hfsig@tapr.org>; Wed, 26 Jul 1995 00:39:58 -0500 

Received: by felix.dircon.co.uk id AA13589 

(5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 26 Jul 1995 06:39:47 +0100 

Message-Id: <199507260539.AA13589@felix.dircon.co.uk> 

Received: from ac037.pool.dircon.co.uk(193.128.230.37) by amnesiac via smap (V1.3) 
id sma013587; Wed Jul 26 06:39:34 1995 

X-Sender: chbrain@dircon.co.uk 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 


Content-Type: text/plain; charset="us-ascii" 
Date: Wed, 26 Jul 1995 04:47:35 +0100 

To: hfsig@tapr.org 

From: chbrain@dircon.co.uk (Charles Brain) 
Subject: Re:IIR filters an 8ary FSK modem 


>Hi Charles, 


>I don't know whether this helped. Good luck anyway. 


> 
>--Johan, KC7WW 
> 

> 

Hello, 


Well after I twigged that the coefficients are different in the TI 
description to the 

PC-DSP program i,e a coeffs are really the B ones etc, things started to 
work better. At start up there is no oscillation and whne a signal is in the 
filters passband there is no problem, however outside the passband the output 
appears almost totally random and is larger than the wanted signal when tuned 
to the passband. 

I am still looking at the 8 ary modem, it seems to work with a 32 point FFT 
fed with real values. Using FIR filters pushes the available processing, so I 
thought I would use IIR as that is what I started with and got nowhere! 

It would be nice to get something that would work on the DSP93, the FFT 
approach is fine on a C50 but I have my doubts about the C25 as I don't think 
there would be enough cycles. 

I know Fredricks managed to get it working with just a C12 so it is possible. 


I was woundering what CAD programs people are using, as I menitioned I am 
using PC-DSP and I have heard MATLAB being mentioned, just curious. 


Regards Charles 


"projects don't slip, they just catch up with reality" 


Charles Brain (G4GUO) 
Chelmsford, Essex. 

E-mail chbrain@dircon.co.uk 
POTS +44 (0)1245 353221 

FAX +44 (0)1245 275448 


From mcdermot@eagle.aud.alcatel.com Thu Jul 27 08:06:05 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id IAA29164 for 
<hfsig@tapr.org>; Thu, 27 Jul 1995 08:05:55 -0500 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AA12254; Thu, 27 Jul 95 08:05:50 CDT 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ1613; Thu, 27 Jul 95 08:05:49 CDT 
Date: Thu, 27 Jul 95 08:05:49 CDT 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 


Message-Id: <9507271305.AA01613@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:494] Re:IIR filters an 8ary FSK modem 


Hello, 
Well after I twigged that the coefficients are different in the TI 
description to the 

PC-DSP program i,e a coeffs are really the B ones etc, things started to 
work better. At start up there is no oscillation and whne a signal is in the 
filters passband there is no problem, however outside the passband the 
output 

> appears almost totally random and is larger than the wanted signal when 
tuned 
to the passband. 

I am still looking at the 8 ary modem, it seems to work with a 32 point FFT 
fed with real values. Using FIR filters pushes the available processing, so 


VV VV VV 


thought I would use IIR as that is what I started with and got nowhere! 
It would be nice to get something that would work on the DSP93, the FFT 
approach is fine on a C50 but I have my doubts about the C25 as I don't 

think 

> there would be enough cycles. 

> I know Fredricks managed to get it working with just a C12 so it is 


VV VHWV VV 


possible. 

> 

> I was woundering what CAD programs people are using, as I menitioned I am 
> using PC-DSP and I have heard MATLAB being mentioned, just curious. 

> 

> Regards Charles 


Charles: a couple of points you might look for: 


IIR filters, as Johan mentions, are sensitive to numerical errors 
due to the feedback. You should make sure that you are rounding, not 
truncating during your calculations (there's some flags in the TMS320 
to control this). Secondly, all intermediate calculations should be 
done with 32-bit arithmetic, not 16 bit arithmetic, and the intermediate 
results must be stored as 32-bit numbers. Additionally, you should 
set the TMS320 flags so that the accumulator clamps at the rail, rather 
than rolling-over. 


And, as Johan has mentioned, if there are any poles close to the 
unit-Z circle, then the required processing accuracy can even exceed 32 
bits. 


You should be very careful in your quantization of the coefficients. 
I would recommend using 32-bit coefficients in many cases. It may not 
be acceptable to take whatever you get from your CAD program and 
truncate the coefficients to 16 bits. You CAD program may or may not 
calculate the coefficients with adequate precision for the application. 


FIR filters, of course do not in general require such high 


precision, but IIR filters do take work to 'tame'. Good luck. 
- Tom, N5SEG 
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Tom McDermott | "All opinions expressed 
Alcatel Network Systems, Inc. | are my own, and do not 
mcdermot@aud.alcatel.com | represent those of Alcatel 

[ ICC'96 Technical Program Secretary ] | Network Systems, Inc." 

[ June 23-27, 1996, Dallas, Tx. ] | 
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From FORRERJ@frl.orst.edu Thu Jul 27 10:59:12 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id KAA31060 for 
<hfsig@tapr.org>; Thu, 27 Jul 1995 10:58:56 -0500 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA00325 for <hfsig@tapr.org>; Thu, 27 Jul 1995 
08:58:54 -0700 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Thu, 27 Jul 95 9:03:41 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 27 Jul 95 8:55:42 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 27 Jul 1995 08:55:41 PST8PDT 

Subject: Re: [HFSIG:492] Bandwidth of digital modulation 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <66F71A05C4B@frl.orst.edu> 
Hi Al, 


----some lines deleted---- 


>I ftp'd an up-to-date (April 26, 1995) copy of part 97 from 
oak.oakland.edu. 

>It's well hidden: /pub/hamradio/arrl/infoserver/rib/part97.txt 

> 

>The bottom line is that there are no explicit bandwidth limitations below 
>28 MHz. There is a maximum FSK shift of 1 kHz and a maximum symbol rate 
>of 300 baud -- I suspect that the FCC expected that would impose a 

>de facto bandwidth limitation based on 97.307(a), but they were 
>probably not thinking about multi-carrier modulation! 

> 

> 

>AL N1AL 

> 


----further lines deleted--- 


You make a good point. To elaborate a little further on this 

issue, here is how HAL justifies Clover II. I quote literally from an 
article from Communications Qaurterly by Bill Henry, K9GWT, and Ray Petit, 
W7GHM. 


"For those who may be wondering how 

this complex modulation fits Part 97 of the 
FCC Rules and Regulations, let us assure 

you that all CLOVER modes are indeed in 
conformance with existing rules. CLOVER 
passes only one data stream and is therefore 
not a "multiplex" modulation format. The 
CLOVER modulation output is audio tones 

that are used to drive the output to an SSB 
transmitter. This is CCIR mode "J2," 

which is allowed. The CLOVER base data 

rate is 31.25 bits-per-second -- well within 
the 300 baud maximum HF limitation. The 

CCIR emisssion designation for CLOVER-II 

is "50QHJ2DEN". 


OK - this obviously deals with a number of issues that we also have been 
discussing. Comments? 


I wish to prepare a few things for the upcoming Digital Conference - 

one is to initiate the motion for updating the rules on digital 
communications. I sense that there is willingness to accept the fact that 
technolgy has advanced. Please think a bit about what the real issues as far 
as rulemaking are concerned to reflect best the needs for modern digital 

HF communications. I will bring that up with the appropiate person(s). Keep 
in mind that we are living in a world community, so I also would like to 
hear what the regulations allow in other countries in this regard. 


Regards, 
--Johan, KC7WW 


From sid@doe.ernet.in Thu Jul 27 23:24:21 1995 
Received: from sangam.ncst.ernet.in (sangam.ncst.ernet.in [144.16.11.1]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id XAAQ8497 for 
<hfsig@tapr.org>; Thu, 27 Jul 1995 23:24:05 -0500 
Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.12/8.6.6) with UUCP 
id JAA28930 for hfsig@tapr.org; Fri, 28 Jul 1995 09:54:53 +0530 
Received: from mahavir.doe.ernet.in by doe.ernet.in (4.1/SMI-4.1-MHS-7.0) 
id AA14974; Fri, 28 Jul 95 09:49:22+050 
Received: by mahavir.doe.ernet.in (4.1/SMI-4.1-MHS-7.0) 
id AAQ4127; Fri, 28 Jul 95 09:50:18+0530 
Date: Fri, 28 Jul 1995 09:50:17 +0530 (GMT+05:30) 
From: Siddhartha Bhattacharjee <sid@doe.ernet.in> 
Subject: Help !!! 
To: hfsig@tapr.org 


In-Reply-To: <9507271305.AA01613@eagle.aud.alcatel.com> 
Message-Id: <Pine.3.89.9507280937 .B3640-0100000@mahavir> 
Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Dear friends, 


I have got badly stuck up for want of a silly information and 
hence decided to trouble the HFSIG guys for a possible help. 


I need the chip details of XR2206 chip with specific application 
to the AFSK generation for 200/170 Hz and 1KHz shift for use 

in HF and VHF use. I tried all possible sources in Delhi and 

with my friends and colleagues. It appears that the EXAR chips are 
not very popular here and hence no manual or application note can 
be found here. I would appreciate an electronic copy of the 
schematics or the data sheet etc., first uuencoded and then 

mailed to sid@doe.ernet.in. 


Thanks to everybody in anticipation. 
73s all round, 


Sid. 

From karn@unix.ka9q.ampr.org Fri Jul 28 02:15:32 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.90.35]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA11507 for 
<hfsig@tapr.org>; Fri, 28 Jul 1995 02:15:28 -0500 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id AAA26888; 
Fri, 28 Jul 1995 00:09:48 -0700 

Date: Fri, 28 Jul 1995 00:09:48 -0700 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199507280709.AAA26888@unix.ka9q.ampr.org> 

To: forrerj@ucs.orst.edu 

CC: hfsig@tapr.org 

In-reply-to: <9507140601.AA12819@ucs.orst.edu> (forrerj@ucs.orst.edu) 
Subject: Re: [HFSIG:465] Re: ANDVT TACTERM Documentation 


>instances. If a "dead" zone or guard interval is used (i.e. the 
>integrator/FFT excuding that part of the signal), he shows a significant 
>improvement in demodulator S/N is possible due to using the guard band. 


Seems to me that applying a window function to the FFT in the 
demod should accomplish this very nicely. 


By the way, I see that the bogus "Reply-To: hfsig@tapr.org" header is 
still present, requiring me to manually edit headers when I reply to 
send a copy to the person in the From: line... 


Phil 
From karn@qualcomm.com Fri Jul 28 02:29:15 1995 
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.90.35]) by 


dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA11609 for 
<hfsig@tapr.org>; Fri, 28 Jul 1995 02:29:10 -0500 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id AAA26950; 
Fri, 28 Jul 1995 00:29:07 -0700 

Date: Fri, 28 Jul 1995 00:29:07 -0700 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199507280729.AAA26950@unix.ka9q.ampr.org> 

To: forrerj@ucs.orst.edu 

CC: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <9507141724.AA15857@ucs.orst.edu> (forrerj@ucs.orst.edu) 
Subject: Re: [HFSIG:471] Re: ANDVT TACTERM Documentation 


>If the sync pre-amble is designed cleverly, it may be possible to write an 
>algorithm that is hunting for it all the time - a daemon. When it sees it, 
>it forces a frame reset. AS an interesting aside, in Pactor, the designers 


HDLC flags work exactly like this -- get a flag, go back to the known 
starting state (and finish whatever packet you were working 

on). Unfortunately, HDLC flags are much too small to be very robust over 
radio. A PN sequence seems more reasonable. 


Phil 


From Danny@edstks1.demon.co.uk Fri Jul 28 09:57:50 1995 

Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by 

dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id JAA14259 for 

<hfsig@tapr.org>; Fri, 28 Jul 1995 09:57:23 -0500 

Received: from post.demon.co.uk by disperse.demon.co.uk id aa17648; 
28 Jul 95 14:49 +0100 

Received: from edstks1.demon.co.uk by post.demon.co.uk id aa05467; 
28 Jul 95 14:49 +0100 

Date: Fri, 28 Jul 1995 08:56:54 GMT 

From: Danny Higgins <Danny@edstks1.demon.co.uk> 

Reply-To: Danny@edstks1.demon.co.uk 

Message-Id: <219@edstks1.demon.co.uk> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:496] Re: Bandwidth of digital modulation 

X-Mailer: PCElm 1.10 

Lines: 68 


In message <66F71A05C4B@frl.orst.edu> hfsig@tapr.org writes: 
Hi Al, 


----some lines deleted---- 


>I ftp'd an up-to-date (April 26, 1995) copy of part 97 from 
oak.oakland.edu. 

>It's well hidden: /pub/hamradio/arrl/infoserver/rib/part97.txt 

> 

>The bottom line is that there are no explicit bandwidth limitations below 
>28 MHz. There is a maximum FSK shift of 1 kHz and a maximum symbol rate 


VV VV VV VV VV MV 
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>of 300 baud -- I suspect that the FCC expected that would impose a 
>de facto bandwidth limitation based on 97.307(a), but they were 
>probably not thinking about multi-carrier modulation! 

> 

> 

>AL NIAL 

> 


----further lines deleted--- 


You make a good point. To elaborate a little further on this 

issue, here is how HAL justifies Clover II. I quote literally from an 
article from Communications Qaurterly by Bill Henry, K9GWT, and Ray Petit, 
W7GHM. 


"For those who may be wondering how 

this complex modulation fits Part 97 of the 
FCC Rules and Regulations, let us assure 

you that all CLOVER modes are indeed in 
conformance with existing rules. CLOVER 
passes only one data stream and is therefore 
not a "multiplex" modulation format. The 
CLOVER modulation output is audio tones 

that are used to drive the output to an SSB 
transmitter. This is CCIR mode "J2," 

which is allowed. The CLOVER base data 

rate is 31.25 bits-per-second -- well within 
the 300 baud maximum HF limitation. The 

CCIR emisssion designation for CLOVER-II 

is "50QHJ2DEN". 


OK - this obviously deals with a number of issues that we also have been 
discussing. Comments? 


I wish to prepare a few things for the upcoming Digital Conference - 

one is to initiate the motion for updating the rules on digital 
communications. I sense that there is willingness to accept the fact that 
technolgy has advanced. Please think a bit about what the real issues as far 
as rulemaking are concerned to reflect best the needs for modern digital 

HF communications. I will bring that up with the appropiate person(s). Keep 
in mind that we are living in a world community, so I also would like to 
hear what the regulations allow in other countries in this regard. 


Regards, 


--Johan, KC7WW 


Hi, Johan. You seem to have sent this to me by mistake. 


I 


have found the HFSIG and have about 1 MByte of back discussion to catch up 


with. How do I join in the discussion? 


Danny Higgins G3XVR 
From bm@lynx.ve3jf.ampr.org Fri Jul 28 12:05:19 1995 
Received: from lynx.ve3jf.ampr.org (lynx.ve3jf.ampr.org [44.135.96.100]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id MAA15504 for 
<hfsig@tapr.org>; Fri, 28 Jul 1995 12:05:11 -0500 
Received: by lynx.ve3jf.ampr.org (Linux Smail3.1.28.1 #14) 
id mOsbspu-0002ruC; Fri, 28 Jul 95 17:04 GMT 
Message-Id: <mOsbspu-0002ruC@lynx.ve3j£.ampr.org> 
From: bm@lynx.ve3j£.ampr.org (Barry McLarnon VE3JF) 
Subject: Re: [HFSIG:498] Re: ANDVT TACTERM Documentation 
To: hfsig@tapr.org 
Date: Fri, 28 Jul 1995 17:04:34 +0000 (GMT) 
In-Reply-To: <199507280709.AAA26888@unix.ka9q.ampr.org> from "Phil Karn" at Jul 
28, 95 02:27:59 am 
X-Mailer: ELM [version 2.4 PL23] 
Content-Type: text 
Content-Length: 889 


> By the way, I see that the bogus "Reply-To: hfsig@tapr.org" header is 
> still present, requiring me to manually edit headers when I reply to 
> send a copy to the person in the From: line... 


It's not bogus, it's intentional. The mailing lists that I administer 
are set up the same way, so that the default is for replies to be seen 
by all, and all can learn from them. The underlying assumption is that 
the list is intended for open discussions, and that the majority of 
replies contain information which is of interest to many on the list. 
The downside is the risk of embarrassment when replies which were 
intended to be personal get sent to the list. Still, I think it's a 
reasonable tradeoff on a high-SNR list such as this one. 


> Phil 


Barry 


Barry McLarnon VE3JF/VA3TCP 

Ottawa Amateur Radio Club Packet Working Group 

Email: bm@hydra.carleton.ca or bm@lynx.ve3jf£.ampr.org 

From karn@qualcomm.com Sat Jul 29 17:28:50 1995 

Received: from qualcomm.com (qualcomm.com [129.46.50.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAA25520 for 
<hfsig@tapr.org>; Sat, 29 Jul 1995 17:28:47 -0500 

Received: from unix.ka9q.ampr.org (root@unix.ka9q.ampr.org [129.46.90.35]) by 
qualcomm.com (8.6.12/QC-MAIN-2.1) with ESMTP id WAA01570 for 
<hfsig%tapr.org@qualcomm.com>; Fri, 28 Jul 1995 22:03:13 -0700 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id NAA28905; 
Fri, 28 Jul 1995 13:49:09 -0700 

Date: Fri, 28 Jul 1995 13:49:09 -0700 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199507282049 .NAA28905@unix.ka9q.ampr.org> 


To: hfsig@tapr.org 

In-reply-to: <5B3E2247CF4@frl.orst.edu> (FORRERJ@fr1l.orst.edu) 
Subject: Re: [HFSIG:486] FCC Regulations for HF digital 
Reply-To: karn@qualcomm.com 


To help the argument along, just for starters consider the 
following: The impact on other nearby stations for a digital 
modulated 100W packed into 500 Hz (0.2W/Hz) compared to 

100W spead over 3KHz (0.033W/Hz). Even with the best filters, 
how wide will a high-powered signal really be? The main concern 


VVV VV 


It may not be 100W spread over 3KHz, it might be much less. One of the 
advantages of going wider is the ability to use LESS total power. So 
you can often reduce W/Hz twice, once by going wider and again by 
using less total power. 


> Another example: Would the principle ideas as used in the cellular 
> phone market have worked if it was based on narrow-band 
> transmission? 


No. There are good reasons, aside from simplicity, why AMPS chose FM 
over SSB. There are even better reasons for going wider, as with CDMA. 


Phil 

From karn@qualcomm.com Sat Jul 29 17:30:11 1995 

Received: from qualcomm.com (qualcomm.com [129.46.50.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAA25566 for 
<hfsig@tapr.org>; Sat, 29 Jul 1995 17:30:06 -0500 

Received: from unix.ka9q.ampr.org (root@unix.ka9q.ampr.org [129.46.90.35]) by 
qualcomm.com (8.6.12/QC-MAIN-2.1) with ESMTP id WAA01565 for 
<hfsig%tapr.org@qualcomm.com>; Fri, 28 Jul 1995 22:03:09 -0700 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id NAA28909; 
Fri, 28 Jul 1995 13:56:01 -0700 

Date: Fri, 28 Jul 1995 13:56:01 -0700 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199507282056.NAA28909@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <199507200221.VAA10073@dingus.n5lyt.datarace.com> (message from Greg 
Jones on Wed, 19 Jul 1995 21:47:13 -0500) 

Subject: Re: [HFSIG:487] Re: FCC Regulations for HF digital 


>So - we should think about talking to the 

>TAPR FCC Reg committee and some of the people at the league about this issue 

>so that they can be aware of it. I would think that Paul Rinaldo is aware of it 
>>n-- the reason that many of the alternate protocols/modes were published 

>in the last Digital Communications Conferecne Proceedings was to be able to 
>have a reference to then include under some 'misc' section of the rules. 


>I forget all the manuvers required. Phil is on the Future Systems 
>Committe and might be able to comment....?? 


Most of the members of the Future Systems committee are already sold 
on this stuff. So is the FCC, for that matter -- they've shown a remarkable 
openness to rule changes that promote technical progress. 


The problem, in my opinion, lies with the average ham and with the 
ARRL leadership who represents them. This has been very apparent in 
the recent attempts to liberalize the SS rules. They don't understand 
the technology and its benefits, and as often happens people fear what 
they don't understand. 


The key here is education, backed up by convincing demonstrations of 
the new technology in action. STAs can be easily had if they're necessary. 


Phil 


From k5yfw@sacdm10.kelly.af.mil Sat Jul 29 23:34:45 1995 
Received: from sacdmi0.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by 
dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id XAA29139 for 
<hfsig@tapr.org>; Sat, 29 Jul 1995 23:34:39 -0500 
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2) 
id mOscPdH-0002AeC; Sat, 29 Jul 95 23:05 CDT 
Message-Id: <mOscPdH-0002AeC@sacdm10.kelly.af.mil> 
Date: Sat, 29 Jul 95 23:05:42 -0500 
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW) 
Subject: Re: [HFSIG:503] Re: FCC Regulations for HF digital 
To: hfsig@tapr.org 
X-orig-date: Sat, 29 Jul 1995 17:34:33 -0500 
X-orig-from: Phil Karn <karn@unix.ka9q.ampr.org> 
X-orig-message-ID: <199507282056.NAA28909@unix.ka9q.ampr.org> 


In Phil's message of 29 Jul 1995 at 1734 CDT, he writes: 

> >So - we should think about talking to the 

> >TAPR FCC Reg committee and some of the people at the league about this issue 
> >so that they can be aware of it. I would think that Paul Rinaldo is aware of 
it 

>>n-- the reason that many of the alternate protocols/modes were published 

>in the last Digital Communications Conferecne Proceedings was to be able to 
>have a reference to then include under some 'misc' section of the rules. 


>I forget all the manuvers required. Phil is on the Future Systems 
>Committe and might be able to comment....?? 


Most of the members of the Future Systems committee are already sold 
on this stuff. So is the FCC, for that matter -- they've shown a remarkable 
openness to rule changes that promote technical progress. 


The problem, in my opinion, lies with the average ham and with the 
ARRL leadership who represents them. This has been very apparent in 
the recent attempts to liberalize the SS rules. They don't understand 
the technology and its benefits, and as often happens people fear what 
they don't understand. 


VV VV VV VV VV VV VV VV 


> 
> The key here is education, backed up by convincing demonstrations of 
> the new technology in action. STAs can be easily had if they're necessary. 


xkkkkkk IMHO, the "convencing demonstration" is the key to acceptance. *xx*x*x*xx 


73, Walt 


PS, sorry of the additional bandwith of the above but felt it had to 
be read before reading my comments. -- k5yfw 
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From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com> 
To: "'HFSIG'" <hfsig@tapr.org> 
Subject: DWAIT/DTIME/T2 KISS parameter number 
Date: Mon, 31 Jul 95 10:13:00 eet 
Message-ID: <301C92BA@ntciteO01les.ntc.nokia.com> 
Encoding: 62 TEXT 
X-Mailer: Microsoft Mail V3.0 


Hello everyone, 


in testing Pawels multitone modem we came across a problem with the DSP4 OS, 
Leonid. It does 

not support the DTIME/DWAIT/T2 parameter. Jarkko promised to code it into 
Leonid but we do not 

have any documents on this feature. The jamming sequence of the modem makes 
the rx fall out of 

synnc which results in immediate ack. if we use maxframe > 1 the ack is 
transmitted on the following 

I frame, creating collision. 


The parameter that we need is the one that adds a wait-time before xeveryx 
transmission. Now 

Leonid works so, that if there is no carrier on the frequency when it wants 
to transmit, it transmits 

immediately. Only if there is a carrier on at the moment of attempted 
transmission it starts the 

persistence / slottime lottery. Today most TNCs have a parameter which 
defines how long to 

wait everytime before transmission. This is called DWAIT/DTIME or T2. 
Correct me if I am wrong. 


What is the KISS parameter number for this parameter? It is needed in order 


to make Leonid 

compatible with existing KISS drivers like TFKISS and TFPCR. If anyone of 
you have an updated 

list of the KISS parameters it would be more than appreciated. 


We have managed to make quite good QSO's with the 9 carrier multitone modem. 
The original 15 

carrier version did not work well, but the 9 carrier version works ok. We 
could not make any reasonable 

file transfer tests because of this KISS parameter lacking. We had a long 
ragchew using the modem 

and could verify that it except this KISS problem it worked quite ok. No 
results are available on the 

bps speed yet. When we can transmit multiple packets we will run several 
file transfer tests in order 

to calculate real transmission speed. We also plan to make more tests on 
longer distances from Jonis 

summer cottage and using the crowded lowbands, when we get a fully operating 
modem. 


The 9QPSK modem is according to our tests a fairly good working model. It is 
sensitive to distortion, but 

works fairly well with low modulation levels. There is a annoying brum on 
the TX line when not transmitting 

which originates from the PSK software, not the electronics. This could be 
checked out by someone who 

knows the software. It is annoying when we use the same rigs for talkback, 
as the hum is coming trough to the mic side and to the SSB audio. 


We will be back with more tests and results after the Leonid modification. 


The test equiupments we use are in the both ends DSP4 and FT757GX TRX with 
vertical antennas. Power has been about 30 W. We have been working on 29.100 
MHz SSB and FM. The distance between me and 

Joni, OH2NJR is about 10 km. 


73, Timo OH6KK/OH2LVZ 
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Date: Mon, 31 Jul 1995 08:45:29 PST8PDT 
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Priority: normal 

X-mailer: PMail v3.0 (R1a) 

Message-ID: <6CF49693604@frl.orst.edu> 

Dear Timo, 

Outstanding! Keep us informed on how things progress. 

I am busy looking into improving the transmitted pulse shaping. This 
probably will clean up spectral leakage and at the same time help a bit on 


tuning the signal. Some form of tuning indication would help things too. 


Keep up the good work - I am sure Pawel will be delighted to hear the 
news when he returns after vaction. 


Good work with the 9-tone version, Frode. Do you think that it is the 
SSB filters causing the problem with the 15-tone version? 


73's 


--Johan, KC7WW 


